T\u00fcr<\/th>\n	Ne de\u011fi\u015fiyor?<\/th>\n	\u00d6rnek<\/th>\n<\/tr>\n<\/thead>\n
State<\/td>\n	Uygulaman\u0131n\/DB’nin durumu de\u011fi\u015fkenlik g\u00f6sterir.<\/td>\n	DB `UPDATE<\/code>, Redis SET<\/code><\/td>\n<\/tr>\n`
I\/O<\/td>\n	Uygulama d\u0131\u015f\u0131ndaki d\u00fcnyada de\u011fi\u015fkenlik g\u00f6sterir.<\/td>\n	HTTP, dosya, S3, SMTP<\/td>\n<\/tr>\n
Temporal<\/td>\n	Zaman\/s\u0131ralama davran\u0131\u015flar\u0131ndaki de\u011fi\u015fiklikler kastedilmektedir.<\/td>\n	`DateTime.Now<\/code>, retry, timeout<\/td>\n<\/tr>\n`
Messaging<\/td>\n	Mesaj ak\u0131\u015flar\u0131yla ba\u015fka servisleri tetikleyerek de\u011fi\u015fkenlik g\u00f6sterir.<\/td>\n	Kafka\/NATS<\/a>\/RabbitMQ<\/a> event publish<\/td>\n<\/tr>\n
Resource<\/td>\n	Kaynak t\u00fcketimi yahut de\u011fi\u015fimi sa\u011flayabilir.<\/td>\n	Transaction, lock, connection, thread<\/td>\n<\/tr>\n
Observability<\/td>\n	Monitoring sistemlerinde de\u011fi\u015fkenlik g\u00f6sterir.<\/td>\n	Log, metric, trace<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/div>\n<\/div>\n Evet, \u015fimdi senaryolara ge\u00e7ebilir ve mimarisel olarak olas\u0131 sorunlara kar\u015f\u0131n nas\u0131l \u00e7\u00f6z\u00fcmler \u00f6nerdi\u011fimize dair isti\u015farede bulunabiliriz;<\/p>\n \n \n Ba\u015fl\u0131klar<\/p>\nToggle<\/span> Senaryo 1 : DB’ye yazd\u0131m, event publish edemedim<\/a><\/li> Senaryo 2 : Event’i iki kere i\u015fledim<\/a><\/li> Senaryo 3 : Exactly-once denen \u015fey esas\u0131nda yok!<\/a><\/li> Senaryo 4 : Retry mekanizmas\u0131 yan etkiyi b\u00fcy\u00fct\u00fcyor<\/a><\/li> Senaryo 5 : Saga Pattern’da side effect \u00fcretebilir!<\/a><\/li> Senaryo 6 : Distributed Lock kullanay\u0131m dedim, i\u015fler daha da kar\u0131\u015ft\u0131<\/a><\/li> Senaryo 7 : Cache invalidation: “DB g\u00fcncel ama kullan\u0131c\u0131 eski veriyi g\u00f6r\u00fcyor”<\/a><\/li><\/ul><\/nav><\/div>\n <\/span>Senaryo 1 : DB’ye yazd\u0131m, event publish edemedim<\/span><\/h4>\n Bir sipari\u015f s\u00fcrecini ele alal\u0131m… Sipari\u015f geldikten sonra, bu sipari\u015fe dair bilgileri veritaban\u0131na kaydediyor ard\u0131ndan sipari\u015fle alakal\u0131 di\u011fer i\u015flemlerin y\u00fcr\u00fct\u00fclebilmesi i\u00e7in message broker ile di\u011fer servislere event f\u0131rlat\u0131yoruz.<\/p>\n \u0130ki ayr\u0131 sisteme ayn\u0131 i\u015f ak\u0131\u015f\u0131 i\u00e7erisinde veri yaz\u0131lmas\u0131 durumlar\u0131na Dual Write<\/a> denir.<\/em><\/p><\/blockquote>\n \u015e\u00f6yle ki;<\/p>\n \n \r\n await dbContext.Orders.AddAsync(order);\r\n await dbContext.SaveChangesAsync();\r\n\r\n await eventBus.PublishAsync(new OrderCreated(order.Id));\r\n<\/pre>\n<\/div>\n \u015eimdi b\u00f6yle bir \u00e7al\u0131\u015fmada veritaban\u0131na kay\u0131t yap\u0131ld\u0131ktan sonra message broker’dan hata al\u0131n\u0131rsa e\u011fer bu durum olduk\u00e7a tehlikeli bir durum arz edecektir. D\u00fc\u015f\u00fcnsenize… veritaban\u0131nda kay\u0131t var, lakin di\u011fer servislerin bundan haberi yok. B\u00f6yle bir durum b\u00fct\u00fcnsel anlamda alenen tutars\u0131zl\u0131\u011fa mahal verecektir. Keza daha da k\u00f6t\u00fcs\u00fc, bu sipari\u015fe dair uygulaman\u0131n nihai sonucu elde edebilmesi i\u00e7in belki de ilgili veritaban\u0131 i\u015fleminin ba\u015ftan tekrar yap\u0131lmas\u0131 gerekecektir. \u00c7\u00fcnk\u00fc, message broker’\u0131n hata verdi\u011fi anda veritaban\u0131na kaydedilen sipari\u015fin hi\u00e7bir anlam\u0131 olmayacakt\u0131r.<\/p>\n \u00c7\u00f6z\u00fcm<\/strong> \n\u0130\u015fte b\u00f6yle bir duruma kar\u015f\u0131n en ideal \u00e7\u00f6z\u00fcm message broker’a g\u00f6nderilecek verinin Outbox Pattern ile \u00f6nceden farkl\u0131 bir tabloya i\u015flenmesi ve ard\u0131ndan ayr\u0131 bir publisher ile bu tablodan event’lerin message broker’a g\u00f6nderilmesidir. Bunun i\u00e7in konuya dair ba\u015ftan sona derinlemesine incelemede bulundu\u011fum Outbox Design Pattern Nedir? Nas\u0131l Uygulan\u0131r? (Inbox Pattern E\u015fli\u011finde)<\/a> ba\u015fl\u0131kl\u0131 makalemi inceleyebilirsiniz.<\/p>\n <\/span>Senaryo 2 : Event’i iki kere i\u015fledim<\/span><\/h4>\n Outbox kullan\u0131nca tabi ki de problemler bitmemektedir \ud83d\ude42 Publisher ile event’leri message broker’a g\u00f6nderdi\u011fimizde bu sefer de consumer’da event’in received edilme s\u00fcrecinde patlama riski vard\u0131r. \u015e\u00f6yle ki, consumer gelen event’i i\u015fleyip veritaban\u0131na kaydedebilir ancak ACK g\u00f6ndermeden \u00e7\u00f6kebilir. Haliyle message broker a\u00e7\u0131s\u0131ndan bu durum “ACK gelmedi, demek ki bu event’e dair i\u015flem yap\u0131lmad\u0131”<\/em> olarak yorumlanabilir.<\/p>\n \u00c7\u00f6z\u00fcm<\/strong> \n\u0130\u015fte burada Idempotency<\/a> kavram\u0131 devreye girmektedir. Yani her bir publish edilecek olan event i\u00e7in \u00f6zel bir anahtar, token veya id gibi de\u011fer \u00fcretecek ve consumer’da bu de\u011ferle birlikte ilgili event’in i\u015flendi\u011fine dair veritaban\u0131na kay\u0131t ataca\u011f\u0131z. B\u00f6ylece consumer’a gelen her event’i kontroll\u00fc bir \u015fekilde i\u015fleme tabi tutacak ve \u00f6nceden bir kay\u0131t yoksa g\u00f6n\u00fcl rahatl\u0131\u011f\u0131yla i\u015fleyerek tutarl\u0131l\u0131k a\u00e7\u0131s\u0131ndan g\u00fcvence sa\u011flayaca\u011f\u0131z!<\/p>\n <\/span>Senaryo 3 : Exactly-once denen \u015fey esas\u0131nda yok!<\/span><\/h4>\n \n \n Exactly-once delivery<\/div>\n Bir mesaj\u0131n consumer’a tam olarak bir kez ula\u015ft\u0131r\u0131lmas\u0131d\u0131r.\n<\/div>\n<\/div>\n \u2194<\/div>\n \n Exactly-once business effect<\/div>\n O mesaj\u0131n temsil etti\u011fi i\u015f operasyonunun tam olarak bir kez ger\u00e7ekle\u015fmesidir.\n<\/div>\n<\/div>\n<\/div>\n Event’in consumer’a bir kez ula\u015ft\u0131r\u0131lmas\u0131, exactly-once business effect<\/em> garantisi vermeyecektir. Event consumer’a ula\u015ft\u0131ktan sonra business i\u015flem sistemin geri kalan\u0131nda istenilen atomiklikte tamamlanamayabilir:<\/p>\n `Event geliyor<\/code> \u2794 Para \u00e7ekiliyor<\/code> \u2794 ACK g\u00f6nderilecek<\/code> \u2794 \ud83d\udca5<\/p>\n` `Para \u00e7ekme i\u015flemi ba\u015far\u0131yla ger\u00e7ekle\u015fmi\u015fken consuemr ACK g\u00f6ndermeden \u00e7\u00f6kerse e\u011fer, sistem event’in i\u015flenip i\u015flenmedi\u011fini kesin olarak bilemeyecektir. Consumer’\u0131n retry\/recovery mekanizmas\u0131 devreye girdi\u011finde ayn\u0131 event yeniden i\u015flenebilir ve para \u00e7ekme gibi non-idempotent bir business operation birden fazla kez \u00e7al\u0131\u015ft\u0131r\u0131labilir.<\/p>\n` Ayn\u0131 durum request\/response s\u00fcre\u00e7leri i\u00e7in de ge\u00e7erlidir. Kullan\u0131c\u0131dan gelen bir request neticesinde i\u015flem ger\u00e7ekle\u015ftirilebilir ama sonras\u0131nda t\u00fcrl\u00fc nedenlerden kaynakl\u0131 istek timeout’a d\u00fc\u015febilir. B\u00f6yle bir durumda kullan\u0131c\u0131n\u0131n fark\u0131nda olmaks\u0131z\u0131n tekrar ayn\u0131 iste\u011fi ger\u00e7ekle\u015ftirmesi y\u00fcksek olas\u0131d\u0131r. Haliyle ayn\u0131 i\u015flem tekrar ger\u00e7ekle\u015ftirilmi\u015f olacakt\u0131r.<\/p>\n `Dolay\u0131s\u0131yla exactly-once delivery<\/em> ile exactly-once business effect<\/em> ayn\u0131 problemler de\u011fildir. \u0130lki mesaj\u0131n consumer’a ka\u00e7 kez ula\u015ft\u0131\u011f\u0131yla ilgilenirken, ikincisi ise mesaj\u0131n tetiklendi\u011fi business i\u015flemin etkili olarak ka\u00e7 kez ger\u00e7ekle\u015fti\u011fiyle ilgilenir.<\/p>\n` `\u00c7\u00f6z\u00fcm<\/strong> \nBu tarz durumlara kar\u015f\u0131n yine Idempotency<\/a> kavram\u0131 olduk\u00e7a ideal \u00e7\u00f6z\u00fcm getirmektedir.<\/p>\n` <\/span>Senaryo 4 : Retry mekanizmas\u0131 yan etkiyi b\u00fcy\u00fct\u00fcyor<\/span><\/h4>\n\u015e\u00f6yle bir kod olduk\u00e7a masum g\u00f6r\u00fcn\u00fcyor olabilir…<\/p>\n\n\r\nawait retryPolicy.ExecuteAsync(async () =>\r\n{\r\n await paymentService.ChargeAsync(order);\r\n});\r\n<\/pre>\n<\/div>\nAncak burada ChargeAsync<\/code> metodu idempotent de\u011filse e\u011fer retry davran\u0131\u015f\u0131 -hata olursa i\u015flemi tekrar yap-<\/em> \u015feklinde de\u011fil, -belirsizlik durumunda yan etkiyi tekrar \u00fcret-<\/em> \u015feklinde bir varl\u0131k g\u00f6sterecektir.<\/p>\n \u00c7\u00f6z\u00fcm<\/strong> \nBurada \u00e7\u00f6z\u00fcmden ziyade dikkat edilmesi gereken noktalar\u0131 \u015f\u00f6yle genelleyebiliriz; e\u011fer retry mekanizmas\u0131 GET<\/code>, DB SELECT<\/code> vs. gibi okuma i\u015flemlerinde kullan\u0131l\u0131yorsa olduk\u00e7a g\u00fcvenlidir, ancak PUT<\/code> ve POST<\/code> i\u015flemlerinde kesinlikle idempotency ile hareket edilmelidir.<\/p>\n<\/span>Senaryo 5 : Saga Pattern’da side effect \u00fcretebilir!<\/span><\/h4>\nDiyelim ki \u015f\u00f6yle a\u015fa\u011f\u0131daki gibi bir sipari\u015f s\u00fcreci olsun;<\/p>\nOrder Service \u2794 Payment Service \u2794 Inventory Service \u2794 Shipping Service\n<\/div>\nBurada her servisin kendi transaction’\u0131na sahip oldu\u011funu d\u00fc\u015f\u00fcnelim.<\/p>\n \u015eimdi varsayal\u0131m ki bir sipari\u015fin i\u015flenmesi s\u00fcrecinde \u015fu sorun meydana gelmi\u015f olsun;<\/p>\nOrder \u2713 \nPayment \u2713 \nInventory \u2713 \nShipping \u2717\n<\/div>\n\u00c7\u00f6z\u00fcm<\/strong> \nB\u00f6yle bir durumda SQL transaction rollback yap\u0131lamaz \u00e7\u00fcnk\u00fc, t\u00fcm bu servislerin her biri ayr\u0131 sistemlerdir. Dolay\u0131s\u0131yla burada Saga ile bir kontrol sa\u011flamal\u0131 ve gerekti\u011fi taktirde compensation transaction<\/a> davran\u0131\u015f\u0131 uygulanmal\u0131d\u0131r.<\/p>\n Ayr\u0131ca Saga i\u00e7in kesinlikle \u015fu makalelere g\u00f6z atman\u0131z\u0131 tavsiye etmekteyim;<\/p>\n Microservice \u2013 Saga \u2013 Commands\/Orchestration Implemantasyonu \u0130le Transaction Y\u00f6netimi<\/a>><\/p>\nMicroservice Mimarilerde Saga Pattern \u0130le Transaction Y\u00f6netimi<\/a><\/li>\n Microservice \u2013 Saga \u2013 Events\/Choreography Implemantasyonu \u0130le Transaction Y\u00f6netimi<\/a><\/li>\n Microservice \u2013 Saga \u2013 Commands\/Orchestration Implemantasyonu \u0130le Transaction Y\u00f6netimi<\/a><\/li>\n<\/ul>\nTabi burada \u015funa dikkat etmekte de fayda g\u00f6rmekteyim. Compensation bir rollback de\u011fildir. \u00c7\u00fcnk\u00fc ChargePayment()<\/code> i\u015fleminin matematiksel olarak RollbackPayment()<\/code> diye bir kar\u015f\u0131l\u0131\u011f\u0131 tabi ki de yoktur! Onun yerine RefundPayment()<\/code> davran\u0131\u015f\u0131 daha ideal olacakt\u0131r! Bu a\u00e7\u0131dan bak\u0131ld\u0131\u011f\u0131nda evet, Saga’n\u0131n kendisi de yeni side effect’ler \u00fcretmektedir.<\/p>\n<\/span>Senaryo 6 : Distributed Lock kullanay\u0131m dedim, i\u015fler daha da kar\u0131\u015ft\u0131<\/span><\/h4>\nVarsayal\u0131m ki iki instance ayn\u0131 job’\u0131 \u00e7al\u0131\u015ft\u0131r\u0131yor olsun;<\/p>\nInstance A \u2500\u2500\u2510 \n \u251c\u2500\u2500\u25ba GenerateInvoice() \nInstance B \u2500\u2500\u2518\n<\/div>\nBurada g\u00f6r\u00fclen olas\u0131 riske kar\u015f\u0131 tabi ki de \u00e7\u00f6z\u00fcm olarak distributed lock ak\u0131llara gelecektir. Ancak burada Time To Live (TTL)<\/em><\/strong> ile ilgili bir durum s\u00f6z konusudur.<\/p>\nTTL, koyulan lock’\u0131n ne kadar s\u00fcre ge\u00e7erli kalaca\u011f\u0131n\u0131 ifade eden bir terimdir.<\/em><\/p><\/blockquote>\n Mesela:<\/p>\nLock: order-processing \nTTL: 30 saniye\n<\/div>\n\u015feklinde bir yap\u0131land\u0131rmadan 30 saniyelik bir kilitleme durumunun s\u00f6z konusu olaca\u011f\u0131 anla\u015f\u0131lmaktad\u0131r. Yani 30 saniye sonra lock otomatik olarak silinecektir. Burada ak\u0131llara \u015fu soru gelebilir: Neden lock’a TTL koyuyoruz?<\/em><\/strong> El-cevap, bunun nedeni lock’\u0131 alan server’\u0131n\/instance’\u0131n \u00f6lme ihtimalidir. E\u011fer al\u0131nan lock’un TTL’i yoksa bu lock sonsuza kadar tutuldu\u011fu storage’da (\u00f6rne\u011fin Redis) kalabilir ve b\u00f6ylece sistem kilitlenebilir. B\u00f6ylece TTL sayesinde lock’\u0131 alan server \u00f6lse dahi belirtilen s\u00fcre kadar sonra lock’un kendili\u011finden ortadan kalkaca\u011f\u0131n\u0131n garantisini vermi\u015f oluyoruz.<\/p>\n \u0130\u015fte distributed lock s\u00fcre\u00e7lerinde tehlikeli nokta tamda burada s\u00f6z konusu olabilmektedir. Diyelim ki A instance’\u0131 TTL 30 saniye olacak \u015fekilde lock’u ald\u0131 ve i\u015f yapmaya ba\u015flad\u0131. Ve varsayal\u0131m ki i\u015flemin 10 saniye civar\u0131nda s\u00fcrmesi bekleniyordu. Ancak beklenmeyen bir durum s\u00f6z konusu oldu ve A instance’\u0131n\u0131n i\u015flemi haddinden uzun s\u00fcrmeye ba\u015flad\u0131 ve TTL zaman\u0131 dolarak expire oldu. Art\u0131k yap\u0131lan i\u015flemle ilgili bir lock yok! Haliyle A instance’\u0131n\u0131n i\u015flemi devam ederken B instance’\u0131 da storage’dan lock isteyebilir ve lock olmad\u0131\u011f\u0131 i\u00e7in i\u015flem s\u00fcrecinde yeni bir lock edinerek A instance’\u0131 hala \u00e7al\u0131\u015f\u0131rken i\u015flemlere ba\u015flayabilir. <\/p>\nA \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba i\u015flem \n i\u015flem \n i\u015flem<\/p>\nB \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba i\u015flem\n<\/p><\/div>\n Bu vaziyette son duruma bakarsak e\u011fer her iki instance g\u00f6z\u00fcnden de lock sahibi oldu\u011fu san\u0131lmaktad\u0131r. Ancak storage’a gidersek son durumda B instance’\u0131n\u0131n lock sahibi oldu\u011fu g\u00f6r\u00fclecektir. Yani arap sa\u00e7\u0131 misali bir problem durumuyla kar\u015f\u0131 kar\u015f\u0131ya kal\u0131nd\u0131\u011f\u0131 a\u015fikard\u0131r.<\/p>\n \u015e\u00f6yle bir senaryoyla d\u00fc\u015f\u00fcnsenize:<\/p>\n\n\nA \n \u2193 \nRedis lock \n \u2193 \nSipari\u015fi i\u015fle \n \u2193 \nBankadan para \u00e7ek\n<\/div>\n<\/p><\/div>\n\nB \n \u2193 \nYeni lock ald\u0131 \n \u2193 \nAyn\u0131 sipari\u015fi i\u015fle \n \u2193 \nBankadan para \u00e7ek\n<\/div>\n<\/p><\/div>\n<\/div>\nFark\u0131ndaysan\u0131z buradaki as\u0131l problem lock’\u0131n bozulmas\u0131 de\u011fil, lock’\u0131n ge\u00e7erlili\u011fi bitmesine ra\u011fmen ilgili server’\u0131n kendini hala yetkili sanmas\u0131d\u0131r. Bu \u00e7ok \u00f6nemli ve kritik bir distributed systems problemidir.<\/p>\n Distribured lock, distributed consistency problemini ortadan kald\u0131rmamakta, yaln\u0131zca belirli bir concurrency problemini y\u00f6netmektedir.<\/em><\/p><\/blockquote>\n \u00c7\u00f6z\u00fcm<\/strong> \n\u00c7\u00f6z\u00fcm olarak bu tarz bir durumda TTL’i s\u00fcrekli yenilemek akla gelebilir. Evet, bu m\u00fcmk\u00fcnd\u00fcr de… Ki b\u00f6ylece lock yap\u0131lan i\u015flem s\u00fcreci boyunca canl\u0131 tutulacakt\u0131r.<\/p>\n TTL’in s\u00fcrekli yenilenmesi davran\u0131\u015f\u0131na lock renewal<\/strong> veya lease renewal<\/strong> denmektedir.<\/em><\/p><\/blockquote>\n Ancak burada yeni problemler de s\u00f6z konusu olabilir. Misal olarak server ile lock TTL’inin tutuldu\u011fu storage aras\u0131ndaki ba\u011flant\u0131 koparsa art\u0131k TTL yenilenemeyecektir ve daha da k\u00f6t\u00fcs\u00fc ilgili server hala \u00e7al\u0131\u015f\u0131rken di\u011fer server storage’dan lock al\u0131p m\u00fckerrer i\u015flem durumu s\u00f6z konusu olabilecektir.<\/p>\n Bu tarz bir duruma kar\u015f\u0131n \u00e7\u00f6z\u00fcm getirebilmek i\u00e7in Fencing Token<\/strong><\/em> kavram\u0131 geli\u015ftirilmi\u015ftir.<\/p>\n \n\n Fencing Token\n <\/div>\n\nDistributed lock’\u0131n s\u00fcresi dolduktan sonra eski lock sahibinin hala i\u015flem yapmas\u0131n\u0131 engellemek i\u00e7in kullan\u0131lan bir davran\u0131\u015ft\u0131r.<\/p>\n\u0130\u015flem mant\u0131\u011f\u0131 olduk\u00e7a basittir: s\u0131ral\u0131 bir numara gibi \u00e7al\u0131\u015fma sergiler.<\/p>\n Diyelim ki; \nA instance’\u0131 lock al\u0131yor…<\/p>\n A \u2192 Lock ald\u0131 \u2192 Token = 41\n<\/div>\nve \u00e7al\u0131\u015fmaya ba\u015fl\u0131yor.<\/p>\n Sonra lock’\u0131n TTL’i doluyor ve B gelip lock al\u0131yor…<\/p>\n B \u2192 Lock ald\u0131 \u2192 Token = 42\n<\/div>\nSon durumda;<\/p>\n A = 41 \u2190 eski \nB = 42 \u2190 yeni\n<\/div>\n\u015feklinde bir vaziyet s\u00f6z konusu oluyor.<\/p>\n Haliyle bu vaziyette A hala \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 san\u0131p database’e bir \u015fey yazmaya \u00e7al\u0131\u015f\u0131rsa;<\/p>\n A \u2192 “Ben 41 token’l\u0131y\u0131m.” \nDB \u2192 “Hay\u0131r. En son 42’yi g\u00f6rd\u00fcm. Sen eskisin.”\n<\/div>\n\u015feklinde bir \u00f6nlemle i\u015flem reddediliyor.\n <\/p><\/div>\n<\/div>\n Unutmay\u0131n! Bir distributed lock’\u0131n sahibi olmak, i\u015flemin geri kalan\u0131nda hala yetkili olundu\u011funun garantisini vermemektedir!<\/em><\/p><\/blockquote>\n <\/span>Senaryo 7 : Cache invalidation: “DB g\u00fcncel ama kullan\u0131c\u0131 eski veriyi g\u00f6r\u00fcyor”<\/span><\/h4>\nRedis’te cache’lenmi\u015f bir verinin veritaban\u0131nda g\u00fcncellenmesi durumunda cache’deki halinin de ya g\u00fcncellenmesi ya da silinmesi gerekti\u011fini hepimiz biliyoruz. Ancak distributed bir mimaride burada bir risk te\u015fkil etti\u011fine dikkatinizi \u00e7ekmek isterim.<\/p>\n Diyelim ki a\u015fa\u011f\u0131daki gibi iki adet API instance’\u0131m\u0131z olsun…<\/p>\n Load Balancer \n \/ \\ \n \/ \\ \nInstance A Instance B \n \u2502 \u2502 \n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \n \u2502 \n Redis \n \u2502 \n SQL Server\n<\/div>\n\u00d6rne\u011fin kullan\u0131c\u0131 taraf\u0131ndan cache’lenmi\u015f bir verinin orjinal veritaban\u0131nda g\u00fcncellendi\u011fini ve bu talebin A instance’\u0131 \u00fczerinden al\u0131nd\u0131\u011f\u0131n\u0131 varsayal\u0131m. Burada ak\u0131\u015f \u015f\u00f6yle olacakt\u0131r;<\/p>\n User \n \u2193 \nInstance A \n \u2193 \n[Update] Data \n \u2193 \n[Delete or Update] Cache\n<\/div>\nAncak farkl\u0131 bir kullan\u0131c\u0131 taraf\u0131ndan gelen ba\u015fka bir talepte ise cache’lenmi\u015f verinin okundu\u011funu bunu da B instance’\u0131n\u0131n kar\u015f\u0131lad\u0131\u011f\u0131n\u0131 varsayal\u0131m.<\/p>\n User \n \u2193 \nInstance B \n \u2193 \nRedis \n \u2193 \n???\n<\/div>\n\u0130\u015fte tam da burada zaman olduk\u00e7a \u00f6nemlidir… A instance’\u0131 veritaban\u0131 g\u00fcncelledikten sonra cache’i hen\u00fcz silemeden ya da g\u00fcncellemeden tam o s\u0131rada B instance’\u0131 taraf\u0131ndan cache’deki veri okunursa e\u011fer i\u015fte burada bir tutars\u0131zl\u0131k durumu s\u00f6z konusu olabilir!<\/p>\n A B \n\u2502 \u2502 \n\u2502 DB \u2192 [New Data] \u2502 \n\u2502 \u2502 \n\u2502 \u251c\u2500\u2500 Redis \u2192 [Old Data] \n\u2502 \u2502 \n\u251c\u2500\u2500 Cache Delete \u2502 \n\u2502 \u2502\n<\/div>\n\u0130\u015fte bu vaziyette ortaya \u00e7\u0131kan probleme cache invalidation<\/em><\/strong> diyoruz…<\/p>\n Cache Invalidation; ger\u00e7ek veri de\u011fi\u015fti\u011finde, onun cache’teki eski kopyas\u0131n\u0131 ne zaman ve nas\u0131l ge\u00e7ersiz hale getirece\u011fiz? problemidir!<\/em><\/p><\/blockquote>\n Keza burada bahsetti\u011fimiz problem bir tek cache’in kullan\u0131lmad\u0131\u011f\u0131 senaryolar i\u00e7in daha y\u0131k\u0131c\u0131 olacakt\u0131r. D\u00fc\u015f\u00fcnsenize, a\u015fa\u011f\u0131daki gibi daha ger\u00e7ek\u00e7i bir durumda;<\/p>\n SQL Server \n \u2502 \n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \n \u2193 \u2193 \u2193 \n Redis Elasticsearch CDN \n \u2502 \u2502 \u2502 \n \u2193 \u2193 \u2193 \nAPI cache Search Web\n<\/div>\nveritaban\u0131ndaki bir de\u011fi\u015fikli\u011fin esas\u0131nda buradaki t\u00fcm yap\u0131lanmalara yans\u0131t\u0131lmas\u0131 gerekmektedir. Bu durumda da side effect explosion<\/em><\/strong> (yan etki patlamas\u0131) ad\u0131n\u0131 verdi\u011fimiz durum cereyan edecektir. \u00c7\u00fcnk\u00fc bir fiziksel de\u011fi\u015fiklik ayn\u0131 zamanda hem cache’e, hem Elasticsearch’e hem de CDN’e yans\u0131t\u0131lacakt\u0131r… Ha yans\u0131t\u0131lm\u0131yor mu? Bu da farkl\u0131 bir s\u0131*\u0131\u015f senaryosuna kar\u015f\u0131l\u0131k gelecektir.<\/p>\n \u00d6rnek durumu daha da derinle\u015ftirirsek e\u011fer;<\/p>\n \n\r\nawait productRepository.UpdateAsync(product);\r\n\r\nawait redis.RemoveAsync($"product:{product.Id}");\r\n\r\nawait searchIndex.UpdateAsync(product);\r\n\r\nawait cdn.InvalidateAsync(product.Id);\r\n\r\nawait eventBus.PublishAsync(new ProductUpdated(product.Id));\r\n<\/pre>\n<\/div>\nvaziyetini ele alal\u0131m. Burada;<\/p>\n DB update \u2713 \nRedis delete \u2713 \nSearch update \u2713 \nCDN invalidate \u2717 \nEvent publish …\n<\/div>\n\u015feklinde bir durumun s\u00f6z konusu oldu\u011funu varsayal\u0131m. Yani dikkat ederseniz DB, Redis ve Elasticsearch tutarl\u0131yken CDN’de bir \u00e7\u00f6kme meydana geldi\u011fi i\u00e7in tutarl\u0131l\u0131k bozulmaktad\u0131r. Yani art\u0131k sistemin farkl\u0131 noktalar\u0131nda ayn\u0131 \u00fcr\u00fcn\u00fcn farkl\u0131 ger\u00e7ekleri mevcuttur.<\/p>\n \u0130\u015fte t\u00fcm bu vurgulad\u0131\u011f\u0131m\u0131z senaryolar ger\u00e7ekten kar\u015f\u0131la\u015f\u0131labilecek kritik durumlard\u0131r. \n\u00c7\u00f6z\u00fcm<\/strong> \nAna veri g\u00fcncellendi\u011fi her an cache’i de g\u00fcncellemeye yahut silmeye \u00f6zen g\u00f6sterilmelidir. Ancak cache’deki bu i\u015flem ba\u015far\u0131s\u0131z olursa yine tutars\u0131zl\u0131k mevzu bahis olaca\u011f\u0131 i\u00e7in dikkat edilmelidir. E\u011fer ki, sistemin ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 bir tek Redis de\u011filse (yani Elasticsearch, CDN vs. varsa) bu servislere do\u011frudan tek tek m\u00fcdahale etmek yerine event-driven bir davran\u0131\u015fla Updated<\/code> event’i yay\u0131nlanabilir ve bu event yay\u0131nland\u0131\u011f\u0131nda sisteme ba\u011fl\u0131 olan t\u00fcm harici servislere gerekli m\u00fcdahalede bulunulabilir. Bu daha do\u011fru ve esnetilebilir bir yakla\u015f\u0131m olacakt\u0131r. Ancak g\u00fcvenilir olabilmesi i\u00e7in Outbox pattern<\/a> ile birlikte Inbox pattern<\/a>‘\u0131 uygulamak gerekecektir. \u00c7\u00fcnk\u00fc bu event’in kaybolma kayg\u0131s\u0131 ile birlikte duplicate olarak i\u015flenmesi durumlar\u0131 da ka\u00e7\u0131n\u0131lmaz olarak mevzu bahis olacakt\u0131r. Eee event kavram\u0131n\u0131n ve Outbox davran\u0131\u015f\u0131n\u0131n oldu\u011fu yerde de ister istemez m\u00fckerrer i\u015flemlere de dikkat edilmesi gerekecek ve sistemin idempotent olarak tasarlanmas\u0131 da gerekecektir.<\/p>\n Nihai olarak; \nFark edildi\u011fi \u00fczere bir\u00e7ok senaryoda Idempotency, Outbox \/ Inbox, Saga ve benzeri pattern’lar s\u00fcrekli kar\u015f\u0131m\u0131za \u00e7\u0131kmaktad\u0131r. Bunun temel sebebi, distributed sistemlerde ba\u015far\u0131s\u0131zl\u0131klar\u0131n istisnai durumlar de\u011fil, tasar\u0131m\u0131n do\u011fal bir par\u00e7as\u0131 olmas\u0131d\u0131r.<\/p>\n Dolay\u0131s\u0131yla bir sistemi tasarlarken bu pattern’lar\u0131 yaln\u0131zca ihtiya\u00e7 ortaya \u00e7\u0131kt\u0131\u011f\u0131nda ba\u015fvurulacak \u00e7\u00f6z\u00fcmler olarak g\u00f6rmek yerine, olas\u0131 ba\u015far\u0131s\u0131zl\u0131k senaryolar\u0131n\u0131, tekrar \u00e7al\u0131\u015ft\u0131r\u0131lmalar\u0131 ve olu\u015fabilecek side effect’leri daha en ba\u015ftan hesaba katarak mimariyi \u015fekillendirmek gerekmektedir.<\/p>\n As\u0131l hedef, t\u00fcm bu pattern’lar\u0131 sisteme dahil etmek de\u011fil, sistemin hangi noktalar\u0131nda tekrar, belirsizlik, k\u0131smi ba\u015far\u0131s\u0131zl\u0131k ve yan etki olu\u015fabilece\u011fini \u00f6nceden g\u00f6rerek, bunlara kar\u015f\u0131 do\u011fru garantileri tasar\u0131m\u0131n bir par\u00e7as\u0131 haline getirmektir. B\u00f6ylece mimariyi sonradan yamalarla d\u00fczeltmek yerine, daha ilk g\u00fcnden g\u00fcvenilir, \u00f6ng\u00f6r\u00fclebilir ve ba\u015far\u0131s\u0131zl\u0131klar kar\u015f\u0131s\u0131nda dayan\u0131kl\u0131 bir yap\u0131ya do\u011fru evriltmemiz en do\u011fru ve ideal zemini sa\u011fl\u0131yor olacakt\u0131r.<\/p>\n \u0130lgilenenlerin faydalanmas\u0131 dile\u011fiyle… \nSonraki yaz\u0131lar\u0131mda g\u00f6r\u00fc\u015fmek \u00fczere… \n\u0130yi \u00e7al\u0131\u015fmalar…<\/p>\n","protected":false},"excerpt":{"rendered":" Merhaba, Bu i\u00e7eri\u011fimizde .NET ile yapt\u0131\u011f\u0131m\u0131z tekrarlayan mimarisel tasar\u0131m sorunlar\u0131na kar\u015f\u0131n nas\u0131l \u00e7\u00f6z\u00fcmler getirebilece\u011fimize dair \u00f6rnek olaylar e\u015fli\u011finde isti\u015fare ediyor olaca\u011f\u0131z. \u00d6zellikle yan etkilerin (side effect) s\u00f6z konusu oldu\u011fu distributed senaryolara odaklanacak ve de\u011ferlendirmede...<\/p>\n","protected":false},"author":1,"featured_media":28910,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5206,3102,3573],"tags":[5759,5753,5752,5758,5756,5757,5760,5754,5755],"class_list":["post-28890","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-net","category-asp-net-core","category-microservices","tag-cache-invalidation","tag-exactly-once-business-effect","tag-exactly-once-delivery","tag-fencing-token","tag-lease-renewal","tag-lock-renewal","tag-side-effect-explosion","tag-time-to-live","tag-ttl"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28890","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/comments?post=28890"}],"version-history":[{"count":17,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28890\/revisions"}],"predecessor-version":[{"id":28909,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28890\/revisions\/28909"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media\/28910"}],"wp:attachment":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media?parent=28890"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/categories?post=28890"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/tags?post=28890"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\n
\r\n await dbContext.Orders.AddAsync(order);\r\n await dbContext.SaveChangesAsync();\r\n\r\n await eventBus.PublishAsync(new OrderCreated(order.Id));\r\n<\/pre>\n<\/div>\n
\u015eimdi b\u00f6yle bir \u00e7al\u0131\u015fmada veritaban\u0131na kay\u0131t yap\u0131ld\u0131ktan sonra message broker’dan hata al\u0131n\u0131rsa e\u011fer bu durum olduk\u00e7a tehlikeli bir durum arz edecektir. D\u00fc\u015f\u00fcnsenize… veritaban\u0131nda kay\u0131t var, lakin di\u011fer servislerin bundan haberi yok. B\u00f6yle bir durum b\u00fct\u00fcnsel anlamda alenen tutars\u0131zl\u0131\u011fa mahal verecektir. Keza daha da k\u00f6t\u00fcs\u00fc, bu sipari\u015fe dair uygulaman\u0131n nihai sonucu elde edebilmesi i\u00e7in belki de ilgili veritaban\u0131 i\u015fleminin ba\u015ftan tekrar yap\u0131lmas\u0131 gerekecektir. \u00c7\u00fcnk\u00fc, message broker’\u0131n hata verdi\u011fi anda veritaban\u0131na kaydedilen sipari\u015fin hi\u00e7bir anlam\u0131 olmayacakt\u0131r.<\/p>\n
\u00c7\u00f6z\u00fcm<\/strong>
\n\u0130\u015fte b\u00f6yle bir duruma kar\u015f\u0131n en ideal \u00e7\u00f6z\u00fcm message broker’a g\u00f6nderilecek verinin Outbox Pattern ile \u00f6nceden farkl\u0131 bir tabloya i\u015flenmesi ve ard\u0131ndan ayr\u0131 bir publisher ile bu tablodan event’lerin message broker’a g\u00f6nderilmesidir. Bunun i\u00e7in konuya dair ba\u015ftan sona derinlemesine incelemede bulundu\u011fum Outbox Design Pattern Nedir? Nas\u0131l Uygulan\u0131r? (Inbox Pattern E\u015fli\u011finde)<\/a> ba\u015fl\u0131kl\u0131 makalemi inceleyebilirsiniz.<\/p>\n
<\/span>Senaryo 2 : Event’i iki kere i\u015fledim<\/span><\/h4>\n
Outbox kullan\u0131nca tabi ki de problemler bitmemektedir \ud83d\ude42 Publisher ile event’leri message broker’a g\u00f6nderdi\u011fimizde bu sefer de consumer’da event’in received edilme s\u00fcrecinde patlama riski vard\u0131r. \u015e\u00f6yle ki, consumer gelen event’i i\u015fleyip veritaban\u0131na kaydedebilir ancak ACK g\u00f6ndermeden \u00e7\u00f6kebilir. Haliyle message broker a\u00e7\u0131s\u0131ndan bu durum “ACK gelmedi, demek ki bu event’e dair i\u015flem yap\u0131lmad\u0131”<\/em> olarak yorumlanabilir.<\/p>\n
\u00c7\u00f6z\u00fcm<\/strong>
\n\u0130\u015fte burada Idempotency<\/a> kavram\u0131 devreye girmektedir. Yani her bir publish edilecek olan event i\u00e7in \u00f6zel bir anahtar, token veya id gibi de\u011fer \u00fcretecek ve consumer’da bu de\u011ferle birlikte ilgili event’in i\u015flendi\u011fine dair veritaban\u0131na kay\u0131t ataca\u011f\u0131z. B\u00f6ylece consumer’a gelen her event’i kontroll\u00fc bir \u015fekilde i\u015fleme tabi tutacak ve \u00f6nceden bir kay\u0131t yoksa g\u00f6n\u00fcl rahatl\u0131\u011f\u0131yla i\u015fleyerek tutarl\u0131l\u0131k a\u00e7\u0131s\u0131ndan g\u00fcvence sa\u011flayaca\u011f\u0131z!<\/p>\n
<\/span>Senaryo 3 : Exactly-once denen \u015fey esas\u0131nda yok!<\/span><\/h4>\n
\n
\n
Exactly-once delivery<\/div>\n
Bir mesaj\u0131n consumer’a tam olarak bir kez ula\u015ft\u0131r\u0131lmas\u0131d\u0131r.\n<\/div>\n<\/div>\n
\u2194<\/div>\n
\n
Exactly-once business effect<\/div>\n
O mesaj\u0131n temsil etti\u011fi i\u015f operasyonunun tam olarak bir kez ger\u00e7ekle\u015fmesidir.\n<\/div>\n<\/div>\n<\/div>\n
Event’in consumer’a bir kez ula\u015ft\u0131r\u0131lmas\u0131, exactly-once business effect<\/em> garantisi vermeyecektir. Event consumer’a ula\u015ft\u0131ktan sonra business i\u015flem sistemin geri kalan\u0131nda istenilen atomiklikte tamamlanamayabilir:<\/p>\n
Event geliyor<\/code> \u2794 Para \u00e7ekiliyor<\/code> \u2794 ACK g\u00f6nderilecek<\/code> \u2794 \ud83d\udca5<\/p>\n
Para \u00e7ekme i\u015flemi ba\u015far\u0131yla ger\u00e7ekle\u015fmi\u015fken consuemr ACK g\u00f6ndermeden \u00e7\u00f6kerse e\u011fer, sistem event’in i\u015flenip i\u015flenmedi\u011fini kesin olarak bilemeyecektir. Consumer’\u0131n retry\/recovery mekanizmas\u0131 devreye girdi\u011finde ayn\u0131 event yeniden i\u015flenebilir ve para \u00e7ekme gibi non-idempotent bir business operation birden fazla kez \u00e7al\u0131\u015ft\u0131r\u0131labilir.<\/p>\n
Ayn\u0131 durum request\/response s\u00fcre\u00e7leri i\u00e7in de ge\u00e7erlidir. Kullan\u0131c\u0131dan gelen bir request neticesinde i\u015flem ger\u00e7ekle\u015ftirilebilir ama sonras\u0131nda t\u00fcrl\u00fc nedenlerden kaynakl\u0131 istek timeout’a d\u00fc\u015febilir. B\u00f6yle bir durumda kullan\u0131c\u0131n\u0131n fark\u0131nda olmaks\u0131z\u0131n tekrar ayn\u0131 iste\u011fi ger\u00e7ekle\u015ftirmesi y\u00fcksek olas\u0131d\u0131r. Haliyle ayn\u0131 i\u015flem tekrar ger\u00e7ekle\u015ftirilmi\u015f olacakt\u0131r.<\/p>\n
Dolay\u0131s\u0131yla exactly-once delivery<\/em> ile exactly-once business effect<\/em> ayn\u0131 problemler de\u011fildir. \u0130lki mesaj\u0131n consumer’a ka\u00e7 kez ula\u015ft\u0131\u011f\u0131yla ilgilenirken, ikincisi ise mesaj\u0131n tetiklendi\u011fi business i\u015flemin etkili olarak ka\u00e7 kez ger\u00e7ekle\u015fti\u011fiyle ilgilenir.<\/p>\n
\u00c7\u00f6z\u00fcm<\/strong> \nBu tarz durumlara kar\u015f\u0131n yine Idempotency<\/a> kavram\u0131 olduk\u00e7a ideal \u00e7\u00f6z\u00fcm getirmektedir.<\/p>\n
<\/span>Senaryo 4 : Retry mekanizmas\u0131 yan etkiyi b\u00fcy\u00fct\u00fcyor<\/span><\/h4>\n\u015e\u00f6yle bir kod olduk\u00e7a masum g\u00f6r\u00fcn\u00fcyor olabilir…<\/p>\n\n\r\nawait retryPolicy.ExecuteAsync(async () =>\r\n{\r\n await paymentService.ChargeAsync(order);\r\n});\r\n<\/pre>\n<\/div>\nAncak burada ChargeAsync<\/code> metodu idempotent de\u011filse e\u011fer retry davran\u0131\u015f\u0131 -hata olursa i\u015flemi tekrar yap-<\/em> \u015feklinde de\u011fil, -belirsizlik durumunda yan etkiyi tekrar \u00fcret-<\/em> \u015feklinde bir varl\u0131k g\u00f6sterecektir.<\/p>\n \u00c7\u00f6z\u00fcm<\/strong> \nBurada \u00e7\u00f6z\u00fcmden ziyade dikkat edilmesi gereken noktalar\u0131 \u015f\u00f6yle genelleyebiliriz; e\u011fer retry mekanizmas\u0131 GET<\/code>, DB SELECT<\/code> vs. gibi okuma i\u015flemlerinde kullan\u0131l\u0131yorsa olduk\u00e7a g\u00fcvenlidir, ancak PUT<\/code> ve POST<\/code> i\u015flemlerinde kesinlikle idempotency ile hareket edilmelidir.<\/p>\n<\/span>Senaryo 5 : Saga Pattern’da side effect \u00fcretebilir!<\/span><\/h4>\nDiyelim ki \u015f\u00f6yle a\u015fa\u011f\u0131daki gibi bir sipari\u015f s\u00fcreci olsun;<\/p>\nOrder Service \u2794 Payment Service \u2794 Inventory Service \u2794 Shipping Service\n<\/div>\nBurada her servisin kendi transaction’\u0131na sahip oldu\u011funu d\u00fc\u015f\u00fcnelim.<\/p>\n \u015eimdi varsayal\u0131m ki bir sipari\u015fin i\u015flenmesi s\u00fcrecinde \u015fu sorun meydana gelmi\u015f olsun;<\/p>\nOrder \u2713 \nPayment \u2713 \nInventory \u2713 \nShipping \u2717\n<\/div>\n\u00c7\u00f6z\u00fcm<\/strong> \nB\u00f6yle bir durumda SQL transaction rollback yap\u0131lamaz \u00e7\u00fcnk\u00fc, t\u00fcm bu servislerin her biri ayr\u0131 sistemlerdir. Dolay\u0131s\u0131yla burada Saga ile bir kontrol sa\u011flamal\u0131 ve gerekti\u011fi taktirde compensation transaction<\/a> davran\u0131\u015f\u0131 uygulanmal\u0131d\u0131r.<\/p>\n Ayr\u0131ca Saga i\u00e7in kesinlikle \u015fu makalelere g\u00f6z atman\u0131z\u0131 tavsiye etmekteyim;<\/p>\n Microservice \u2013 Saga \u2013 Commands\/Orchestration Implemantasyonu \u0130le Transaction Y\u00f6netimi<\/a>><\/p>\nMicroservice Mimarilerde Saga Pattern \u0130le Transaction Y\u00f6netimi<\/a><\/li>\n Microservice \u2013 Saga \u2013 Events\/Choreography Implemantasyonu \u0130le Transaction Y\u00f6netimi<\/a><\/li>\n Microservice \u2013 Saga \u2013 Commands\/Orchestration Implemantasyonu \u0130le Transaction Y\u00f6netimi<\/a><\/li>\n<\/ul>\nTabi burada \u015funa dikkat etmekte de fayda g\u00f6rmekteyim. Compensation bir rollback de\u011fildir. \u00c7\u00fcnk\u00fc ChargePayment()<\/code> i\u015fleminin matematiksel olarak RollbackPayment()<\/code> diye bir kar\u015f\u0131l\u0131\u011f\u0131 tabi ki de yoktur! Onun yerine RefundPayment()<\/code> davran\u0131\u015f\u0131 daha ideal olacakt\u0131r! Bu a\u00e7\u0131dan bak\u0131ld\u0131\u011f\u0131nda evet, Saga’n\u0131n kendisi de yeni side effect’ler \u00fcretmektedir.<\/p>\n<\/span>Senaryo 6 : Distributed Lock kullanay\u0131m dedim, i\u015fler daha da kar\u0131\u015ft\u0131<\/span><\/h4>\nVarsayal\u0131m ki iki instance ayn\u0131 job’\u0131 \u00e7al\u0131\u015ft\u0131r\u0131yor olsun;<\/p>\nInstance A \u2500\u2500\u2510 \n \u251c\u2500\u2500\u25ba GenerateInvoice() \nInstance B \u2500\u2500\u2518\n<\/div>\nBurada g\u00f6r\u00fclen olas\u0131 riske kar\u015f\u0131 tabi ki de \u00e7\u00f6z\u00fcm olarak distributed lock ak\u0131llara gelecektir. Ancak burada Time To Live (TTL)<\/em><\/strong> ile ilgili bir durum s\u00f6z konusudur.<\/p>\nTTL, koyulan lock’\u0131n ne kadar s\u00fcre ge\u00e7erli kalaca\u011f\u0131n\u0131 ifade eden bir terimdir.<\/em><\/p><\/blockquote>\n Mesela:<\/p>\nLock: order-processing \nTTL: 30 saniye\n<\/div>\n\u015feklinde bir yap\u0131land\u0131rmadan 30 saniyelik bir kilitleme durumunun s\u00f6z konusu olaca\u011f\u0131 anla\u015f\u0131lmaktad\u0131r. Yani 30 saniye sonra lock otomatik olarak silinecektir. Burada ak\u0131llara \u015fu soru gelebilir: Neden lock’a TTL koyuyoruz?<\/em><\/strong> El-cevap, bunun nedeni lock’\u0131 alan server’\u0131n\/instance’\u0131n \u00f6lme ihtimalidir. E\u011fer al\u0131nan lock’un TTL’i yoksa bu lock sonsuza kadar tutuldu\u011fu storage’da (\u00f6rne\u011fin Redis) kalabilir ve b\u00f6ylece sistem kilitlenebilir. B\u00f6ylece TTL sayesinde lock’\u0131 alan server \u00f6lse dahi belirtilen s\u00fcre kadar sonra lock’un kendili\u011finden ortadan kalkaca\u011f\u0131n\u0131n garantisini vermi\u015f oluyoruz.<\/p>\n \u0130\u015fte distributed lock s\u00fcre\u00e7lerinde tehlikeli nokta tamda burada s\u00f6z konusu olabilmektedir. Diyelim ki A instance’\u0131 TTL 30 saniye olacak \u015fekilde lock’u ald\u0131 ve i\u015f yapmaya ba\u015flad\u0131. Ve varsayal\u0131m ki i\u015flemin 10 saniye civar\u0131nda s\u00fcrmesi bekleniyordu. Ancak beklenmeyen bir durum s\u00f6z konusu oldu ve A instance’\u0131n\u0131n i\u015flemi haddinden uzun s\u00fcrmeye ba\u015flad\u0131 ve TTL zaman\u0131 dolarak expire oldu. Art\u0131k yap\u0131lan i\u015flemle ilgili bir lock yok! Haliyle A instance’\u0131n\u0131n i\u015flemi devam ederken B instance’\u0131 da storage’dan lock isteyebilir ve lock olmad\u0131\u011f\u0131 i\u00e7in i\u015flem s\u00fcrecinde yeni bir lock edinerek A instance’\u0131 hala \u00e7al\u0131\u015f\u0131rken i\u015flemlere ba\u015flayabilir. <\/p>\nA \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba i\u015flem \n i\u015flem \n i\u015flem<\/p>\nB \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba i\u015flem\n<\/p><\/div>\n Bu vaziyette son duruma bakarsak e\u011fer her iki instance g\u00f6z\u00fcnden de lock sahibi oldu\u011fu san\u0131lmaktad\u0131r. Ancak storage’a gidersek son durumda B instance’\u0131n\u0131n lock sahibi oldu\u011fu g\u00f6r\u00fclecektir. Yani arap sa\u00e7\u0131 misali bir problem durumuyla kar\u015f\u0131 kar\u015f\u0131ya kal\u0131nd\u0131\u011f\u0131 a\u015fikard\u0131r.<\/p>\n \u015e\u00f6yle bir senaryoyla d\u00fc\u015f\u00fcnsenize:<\/p>\n\n\nA \n \u2193 \nRedis lock \n \u2193 \nSipari\u015fi i\u015fle \n \u2193 \nBankadan para \u00e7ek\n<\/div>\n<\/p><\/div>\n\nB \n \u2193 \nYeni lock ald\u0131 \n \u2193 \nAyn\u0131 sipari\u015fi i\u015fle \n \u2193 \nBankadan para \u00e7ek\n<\/div>\n<\/p><\/div>\n<\/div>\nFark\u0131ndaysan\u0131z buradaki as\u0131l problem lock’\u0131n bozulmas\u0131 de\u011fil, lock’\u0131n ge\u00e7erlili\u011fi bitmesine ra\u011fmen ilgili server’\u0131n kendini hala yetkili sanmas\u0131d\u0131r. Bu \u00e7ok \u00f6nemli ve kritik bir distributed systems problemidir.<\/p>\n Distribured lock, distributed consistency problemini ortadan kald\u0131rmamakta, yaln\u0131zca belirli bir concurrency problemini y\u00f6netmektedir.<\/em><\/p><\/blockquote>\n \u00c7\u00f6z\u00fcm<\/strong> \n\u00c7\u00f6z\u00fcm olarak bu tarz bir durumda TTL’i s\u00fcrekli yenilemek akla gelebilir. Evet, bu m\u00fcmk\u00fcnd\u00fcr de… Ki b\u00f6ylece lock yap\u0131lan i\u015flem s\u00fcreci boyunca canl\u0131 tutulacakt\u0131r.<\/p>\n TTL’in s\u00fcrekli yenilenmesi davran\u0131\u015f\u0131na lock renewal<\/strong> veya lease renewal<\/strong> denmektedir.<\/em><\/p><\/blockquote>\n Ancak burada yeni problemler de s\u00f6z konusu olabilir. Misal olarak server ile lock TTL’inin tutuldu\u011fu storage aras\u0131ndaki ba\u011flant\u0131 koparsa art\u0131k TTL yenilenemeyecektir ve daha da k\u00f6t\u00fcs\u00fc ilgili server hala \u00e7al\u0131\u015f\u0131rken di\u011fer server storage’dan lock al\u0131p m\u00fckerrer i\u015flem durumu s\u00f6z konusu olabilecektir.<\/p>\n Bu tarz bir duruma kar\u015f\u0131n \u00e7\u00f6z\u00fcm getirebilmek i\u00e7in Fencing Token<\/strong><\/em> kavram\u0131 geli\u015ftirilmi\u015ftir.<\/p>\n \n\n Fencing Token\n <\/div>\n\nDistributed lock’\u0131n s\u00fcresi dolduktan sonra eski lock sahibinin hala i\u015flem yapmas\u0131n\u0131 engellemek i\u00e7in kullan\u0131lan bir davran\u0131\u015ft\u0131r.<\/p>\n\u0130\u015flem mant\u0131\u011f\u0131 olduk\u00e7a basittir: s\u0131ral\u0131 bir numara gibi \u00e7al\u0131\u015fma sergiler.<\/p>\n Diyelim ki; \nA instance’\u0131 lock al\u0131yor…<\/p>\n A \u2192 Lock ald\u0131 \u2192 Token = 41\n<\/div>\nve \u00e7al\u0131\u015fmaya ba\u015fl\u0131yor.<\/p>\n Sonra lock’\u0131n TTL’i doluyor ve B gelip lock al\u0131yor…<\/p>\n B \u2192 Lock ald\u0131 \u2192 Token = 42\n<\/div>\nSon durumda;<\/p>\n A = 41 \u2190 eski \nB = 42 \u2190 yeni\n<\/div>\n\u015feklinde bir vaziyet s\u00f6z konusu oluyor.<\/p>\n Haliyle bu vaziyette A hala \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 san\u0131p database’e bir \u015fey yazmaya \u00e7al\u0131\u015f\u0131rsa;<\/p>\n A \u2192 “Ben 41 token’l\u0131y\u0131m.” \nDB \u2192 “Hay\u0131r. En son 42’yi g\u00f6rd\u00fcm. Sen eskisin.”\n<\/div>\n\u015feklinde bir \u00f6nlemle i\u015flem reddediliyor.\n <\/p><\/div>\n<\/div>\n Unutmay\u0131n! Bir distributed lock’\u0131n sahibi olmak, i\u015flemin geri kalan\u0131nda hala yetkili olundu\u011funun garantisini vermemektedir!<\/em><\/p><\/blockquote>\n <\/span>Senaryo 7 : Cache invalidation: “DB g\u00fcncel ama kullan\u0131c\u0131 eski veriyi g\u00f6r\u00fcyor”<\/span><\/h4>\nRedis’te cache’lenmi\u015f bir verinin veritaban\u0131nda g\u00fcncellenmesi durumunda cache’deki halinin de ya g\u00fcncellenmesi ya da silinmesi gerekti\u011fini hepimiz biliyoruz. Ancak distributed bir mimaride burada bir risk te\u015fkil etti\u011fine dikkatinizi \u00e7ekmek isterim.<\/p>\n Diyelim ki a\u015fa\u011f\u0131daki gibi iki adet API instance’\u0131m\u0131z olsun…<\/p>\n Load Balancer \n \/ \\ \n \/ \\ \nInstance A Instance B \n \u2502 \u2502 \n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \n \u2502 \n Redis \n \u2502 \n SQL Server\n<\/div>\n\u00d6rne\u011fin kullan\u0131c\u0131 taraf\u0131ndan cache’lenmi\u015f bir verinin orjinal veritaban\u0131nda g\u00fcncellendi\u011fini ve bu talebin A instance’\u0131 \u00fczerinden al\u0131nd\u0131\u011f\u0131n\u0131 varsayal\u0131m. Burada ak\u0131\u015f \u015f\u00f6yle olacakt\u0131r;<\/p>\n User \n \u2193 \nInstance A \n \u2193 \n[Update] Data \n \u2193 \n[Delete or Update] Cache\n<\/div>\nAncak farkl\u0131 bir kullan\u0131c\u0131 taraf\u0131ndan gelen ba\u015fka bir talepte ise cache’lenmi\u015f verinin okundu\u011funu bunu da B instance’\u0131n\u0131n kar\u015f\u0131lad\u0131\u011f\u0131n\u0131 varsayal\u0131m.<\/p>\n User \n \u2193 \nInstance B \n \u2193 \nRedis \n \u2193 \n???\n<\/div>\n\u0130\u015fte tam da burada zaman olduk\u00e7a \u00f6nemlidir… A instance’\u0131 veritaban\u0131 g\u00fcncelledikten sonra cache’i hen\u00fcz silemeden ya da g\u00fcncellemeden tam o s\u0131rada B instance’\u0131 taraf\u0131ndan cache’deki veri okunursa e\u011fer i\u015fte burada bir tutars\u0131zl\u0131k durumu s\u00f6z konusu olabilir!<\/p>\n A B \n\u2502 \u2502 \n\u2502 DB \u2192 [New Data] \u2502 \n\u2502 \u2502 \n\u2502 \u251c\u2500\u2500 Redis \u2192 [Old Data] \n\u2502 \u2502 \n\u251c\u2500\u2500 Cache Delete \u2502 \n\u2502 \u2502\n<\/div>\n\u0130\u015fte bu vaziyette ortaya \u00e7\u0131kan probleme cache invalidation<\/em><\/strong> diyoruz…<\/p>\n Cache Invalidation; ger\u00e7ek veri de\u011fi\u015fti\u011finde, onun cache’teki eski kopyas\u0131n\u0131 ne zaman ve nas\u0131l ge\u00e7ersiz hale getirece\u011fiz? problemidir!<\/em><\/p><\/blockquote>\n Keza burada bahsetti\u011fimiz problem bir tek cache’in kullan\u0131lmad\u0131\u011f\u0131 senaryolar i\u00e7in daha y\u0131k\u0131c\u0131 olacakt\u0131r. D\u00fc\u015f\u00fcnsenize, a\u015fa\u011f\u0131daki gibi daha ger\u00e7ek\u00e7i bir durumda;<\/p>\n SQL Server \n \u2502 \n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \n \u2193 \u2193 \u2193 \n Redis Elasticsearch CDN \n \u2502 \u2502 \u2502 \n \u2193 \u2193 \u2193 \nAPI cache Search Web\n<\/div>\nveritaban\u0131ndaki bir de\u011fi\u015fikli\u011fin esas\u0131nda buradaki t\u00fcm yap\u0131lanmalara yans\u0131t\u0131lmas\u0131 gerekmektedir. Bu durumda da side effect explosion<\/em><\/strong> (yan etki patlamas\u0131) ad\u0131n\u0131 verdi\u011fimiz durum cereyan edecektir. \u00c7\u00fcnk\u00fc bir fiziksel de\u011fi\u015fiklik ayn\u0131 zamanda hem cache’e, hem Elasticsearch’e hem de CDN’e yans\u0131t\u0131lacakt\u0131r… Ha yans\u0131t\u0131lm\u0131yor mu? Bu da farkl\u0131 bir s\u0131*\u0131\u015f senaryosuna kar\u015f\u0131l\u0131k gelecektir.<\/p>\n \u00d6rnek durumu daha da derinle\u015ftirirsek e\u011fer;<\/p>\n \n\r\nawait productRepository.UpdateAsync(product);\r\n\r\nawait redis.RemoveAsync($"product:{product.Id}");\r\n\r\nawait searchIndex.UpdateAsync(product);\r\n\r\nawait cdn.InvalidateAsync(product.Id);\r\n\r\nawait eventBus.PublishAsync(new ProductUpdated(product.Id));\r\n<\/pre>\n<\/div>\nvaziyetini ele alal\u0131m. Burada;<\/p>\n DB update \u2713 \nRedis delete \u2713 \nSearch update \u2713 \nCDN invalidate \u2717 \nEvent publish …\n<\/div>\n\u015feklinde bir durumun s\u00f6z konusu oldu\u011funu varsayal\u0131m. Yani dikkat ederseniz DB, Redis ve Elasticsearch tutarl\u0131yken CDN’de bir \u00e7\u00f6kme meydana geldi\u011fi i\u00e7in tutarl\u0131l\u0131k bozulmaktad\u0131r. Yani art\u0131k sistemin farkl\u0131 noktalar\u0131nda ayn\u0131 \u00fcr\u00fcn\u00fcn farkl\u0131 ger\u00e7ekleri mevcuttur.<\/p>\n \u0130\u015fte t\u00fcm bu vurgulad\u0131\u011f\u0131m\u0131z senaryolar ger\u00e7ekten kar\u015f\u0131la\u015f\u0131labilecek kritik durumlard\u0131r. \n\u00c7\u00f6z\u00fcm<\/strong> \nAna veri g\u00fcncellendi\u011fi her an cache’i de g\u00fcncellemeye yahut silmeye \u00f6zen g\u00f6sterilmelidir. Ancak cache’deki bu i\u015flem ba\u015far\u0131s\u0131z olursa yine tutars\u0131zl\u0131k mevzu bahis olaca\u011f\u0131 i\u00e7in dikkat edilmelidir. E\u011fer ki, sistemin ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 bir tek Redis de\u011filse (yani Elasticsearch, CDN vs. varsa) bu servislere do\u011frudan tek tek m\u00fcdahale etmek yerine event-driven bir davran\u0131\u015fla Updated<\/code> event’i yay\u0131nlanabilir ve bu event yay\u0131nland\u0131\u011f\u0131nda sisteme ba\u011fl\u0131 olan t\u00fcm harici servislere gerekli m\u00fcdahalede bulunulabilir. Bu daha do\u011fru ve esnetilebilir bir yakla\u015f\u0131m olacakt\u0131r. Ancak g\u00fcvenilir olabilmesi i\u00e7in Outbox pattern<\/a> ile birlikte Inbox pattern<\/a>‘\u0131 uygulamak gerekecektir. \u00c7\u00fcnk\u00fc bu event’in kaybolma kayg\u0131s\u0131 ile birlikte duplicate olarak i\u015flenmesi durumlar\u0131 da ka\u00e7\u0131n\u0131lmaz olarak mevzu bahis olacakt\u0131r. Eee event kavram\u0131n\u0131n ve Outbox davran\u0131\u015f\u0131n\u0131n oldu\u011fu yerde de ister istemez m\u00fckerrer i\u015flemlere de dikkat edilmesi gerekecek ve sistemin idempotent olarak tasarlanmas\u0131 da gerekecektir.<\/p>\n Nihai olarak; \nFark edildi\u011fi \u00fczere bir\u00e7ok senaryoda Idempotency, Outbox \/ Inbox, Saga ve benzeri pattern’lar s\u00fcrekli kar\u015f\u0131m\u0131za \u00e7\u0131kmaktad\u0131r. Bunun temel sebebi, distributed sistemlerde ba\u015far\u0131s\u0131zl\u0131klar\u0131n istisnai durumlar de\u011fil, tasar\u0131m\u0131n do\u011fal bir par\u00e7as\u0131 olmas\u0131d\u0131r.<\/p>\n Dolay\u0131s\u0131yla bir sistemi tasarlarken bu pattern’lar\u0131 yaln\u0131zca ihtiya\u00e7 ortaya \u00e7\u0131kt\u0131\u011f\u0131nda ba\u015fvurulacak \u00e7\u00f6z\u00fcmler olarak g\u00f6rmek yerine, olas\u0131 ba\u015far\u0131s\u0131zl\u0131k senaryolar\u0131n\u0131, tekrar \u00e7al\u0131\u015ft\u0131r\u0131lmalar\u0131 ve olu\u015fabilecek side effect’leri daha en ba\u015ftan hesaba katarak mimariyi \u015fekillendirmek gerekmektedir.<\/p>\n As\u0131l hedef, t\u00fcm bu pattern’lar\u0131 sisteme dahil etmek de\u011fil, sistemin hangi noktalar\u0131nda tekrar, belirsizlik, k\u0131smi ba\u015far\u0131s\u0131zl\u0131k ve yan etki olu\u015fabilece\u011fini \u00f6nceden g\u00f6rerek, bunlara kar\u015f\u0131 do\u011fru garantileri tasar\u0131m\u0131n bir par\u00e7as\u0131 haline getirmektir. B\u00f6ylece mimariyi sonradan yamalarla d\u00fczeltmek yerine, daha ilk g\u00fcnden g\u00fcvenilir, \u00f6ng\u00f6r\u00fclebilir ve ba\u015far\u0131s\u0131zl\u0131klar kar\u015f\u0131s\u0131nda dayan\u0131kl\u0131 bir yap\u0131ya do\u011fru evriltmemiz en do\u011fru ve ideal zemini sa\u011fl\u0131yor olacakt\u0131r.<\/p>\n \u0130lgilenenlerin faydalanmas\u0131 dile\u011fiyle… \nSonraki yaz\u0131lar\u0131mda g\u00f6r\u00fc\u015fmek \u00fczere… \n\u0130yi \u00e7al\u0131\u015fmalar…<\/p>\n","protected":false},"excerpt":{"rendered":" Merhaba, Bu i\u00e7eri\u011fimizde .NET ile yapt\u0131\u011f\u0131m\u0131z tekrarlayan mimarisel tasar\u0131m sorunlar\u0131na kar\u015f\u0131n nas\u0131l \u00e7\u00f6z\u00fcmler getirebilece\u011fimize dair \u00f6rnek olaylar e\u015fli\u011finde isti\u015fare ediyor olaca\u011f\u0131z. \u00d6zellikle yan etkilerin (side effect) s\u00f6z konusu oldu\u011fu distributed senaryolara odaklanacak ve de\u011ferlendirmede...<\/p>\n","protected":false},"author":1,"featured_media":28910,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5206,3102,3573],"tags":[5759,5753,5752,5758,5756,5757,5760,5754,5755],"class_list":["post-28890","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-net","category-asp-net-core","category-microservices","tag-cache-invalidation","tag-exactly-once-business-effect","tag-exactly-once-delivery","tag-fencing-token","tag-lease-renewal","tag-lock-renewal","tag-side-effect-explosion","tag-time-to-live","tag-ttl"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28890","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/comments?post=28890"}],"version-history":[{"count":17,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28890\/revisions"}],"predecessor-version":[{"id":28909,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28890\/revisions\/28909"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media\/28910"}],"wp:attachment":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media?parent=28890"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/categories?post=28890"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/tags?post=28890"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}