Modern yaz\u0131l\u0131m mimarilerinde, \u00f6zellikle mikroservislerin yayg\u0131nla\u015fmas\u0131yla birlikte, sistemler aras\u0131ndaki ileti\u015fim ve veri tutarl\u0131l\u0131\u011f\u0131 her zamankinden daha karma\u015f\u0131k hale geldi. Bir i\u015flemin veritaban\u0131nda ba\u015far\u0131yla tamamlanmas\u0131na ra\u011fmen, ilgili bir olay\u0131n mesaj broker\u0131na iletilememesi, bir\u00e7ok geli\u015ftiricinin k\u00e2busu haline gelebilir. Bu durum, sistemler aras\u0131nda veri tutars\u0131zl\u0131klar\u0131na yol a\u00e7arak i\u015f s\u00fcre\u00e7lerini aksatabilir ve kullan\u0131c\u0131 deneyimini olumsuz etkileyebilir. Peki, veritaban\u0131 “ba\u015far\u0131l\u0131” derken, mesaj broker\u0131 neden “tekrar dene” der ve bu \u00e7eli\u015fkiyi nas\u0131l \u00e7\u00f6zebiliriz?<\/p>\n
G\u00fcn\u00fcm\u00fcz\u00fcn \u00f6l\u00e7eklenebilir ve esnek uygulamalar\u0131 genellikle asenkron (e\u015f zamans\u0131z) ileti\u015fim modellerini benimser. Bu modellerde, bir i\u015flem ba\u015flat\u0131ld\u0131\u011f\u0131nda, sonucun an\u0131nda d\u00f6nmesi beklenmez; bunun yerine, i\u015flem arka planda y\u00fcr\u00fct\u00fcl\u00fcr ve sonu\u00e7 daha sonra iletilir. Bu yakla\u015f\u0131m, sistem performans\u0131n\u0131 art\u0131r\u0131r ve kaynak kullan\u0131m\u0131n\u0131 optimize ederken, beraberinde \u00f6nemli zorluklar\u0131 da getirir. \u00d6zellikle, bir i\u015flemin birden fazla ba\u011f\u0131ms\u0131z bile\u015feni etkiledi\u011fi da\u011f\u0131t\u0131k sistemlerde, bu bile\u015fenlerin t\u00fcm\u00fcn\u00fcn ayn\u0131 anda ba\u015far\u0131l\u0131 olmas\u0131 garanti edilemez.<\/p>\n
Tipik bir senaryoda, bir kullan\u0131c\u0131 bir e-ticaret sitesinde sipari\u015f verdi\u011finde, bu i\u015flem sadece sipari\u015fin veritaban\u0131na kaydedilmesiyle bitmez. Ayn\u0131 zamanda, \u00f6deme sistemine bir bildirim g\u00f6nderilmesi, envanterin g\u00fcncellenmesi, m\u00fc\u015fteriye e-posta onay\u0131 g\u00f6nderilmesi ve belki de kargo \u015firketine sipari\u015f bilgisinin iletilmesi gibi bir\u00e7ok ard\u0131\u015f\u0131k veya paralel ad\u0131m tetiklenir. Bu ad\u0131mlar\u0131n her biri farkl\u0131 servisler taraf\u0131ndan y\u00f6netilebilir ve genellikle mesaj brokerlar\u0131 (message brokers) arac\u0131l\u0131\u011f\u0131yla ileti\u015fim kurarlar. \u00d6rne\u011fin, sipari\u015f servisi veritaban\u0131na kayd\u0131 yapt\u0131ktan sonra, bir Ancak, burada kritik bir nokta ortaya \u00e7\u0131kar: Veritaban\u0131na yazma i\u015flemi ba\u015far\u0131l\u0131 oldu\u011funda, mesaj broker\u0131na mesaj g\u00f6nderme i\u015flemi de ayn\u0131 atomik (atomic) i\u015flem i\u00e7inde mi ger\u00e7ekle\u015fir? \u00c7o\u011fu zaman hay\u0131r. Veritaban\u0131 i\u015flemi kendi i\u00e7inde bir atomik birimdir (ACID \u00f6zelliklerini sa\u011flar: Atomicity, Consistency, Isolation, Durability). Yani ya tamamen ba\u015far\u0131l\u0131 olur ya da tamamen geri al\u0131n\u0131r (rollback). Ancak, veritaban\u0131 i\u015flemi ba\u015far\u0131l\u0131 olduktan sonra ayr\u0131 bir ad\u0131m olarak mesaj broker\u0131na mesaj g\u00f6ndermeye \u00e7al\u0131\u015f\u0131ld\u0131\u011f\u0131nda, bu iki i\u015flem birbirinden ba\u011f\u0131ms\u0131z hale gelir. E\u011fer tam bu noktada bir a\u011f kesintisi, mesaj broker\u0131n\u0131n ge\u00e7ici olarak kullan\u0131lamamas\u0131 veya uygulaman\u0131n kendisinin \u00e7\u00f6kmesi gibi bir sorun ya\u015fan\u0131rsa, veritaban\u0131ndaki veri g\u00fcncelken, ilgili olay mesaj broker\u0131na ula\u015famaz.<\/p>\n Bu durum, sistemde bir tutars\u0131zl\u0131k yarat\u0131r. Veritaban\u0131nda sipari\u015f “olu\u015fturuldu” olarak g\u00f6r\u00fcn\u00fcrken, \u00f6deme servisi, envanter servisi veya e-posta bildirim servisi bu sipari\u015ften haberdar olmaz. Sonu\u00e7 olarak, m\u00fc\u015fteri \u00f6deme yapmas\u0131na ra\u011fmen \u00fcr\u00fcn\u00fcn\u00fc alamaz, envanter g\u00fcncellenmedi\u011fi i\u00e7in stok hatalar\u0131 ya\u015fan\u0131r veya m\u00fc\u015fteri onay e-postas\u0131 almad\u0131\u011f\u0131 i\u00e7in endi\u015felenir. Bu t\u00fcr tutars\u0131zl\u0131klar, manuel m\u00fcdahale gerektiren karma\u015f\u0131k sorunlara yol a\u00e7ar, operasyonel maliyetleri art\u0131r\u0131r ve m\u00fc\u015fteri memnuniyetini ciddi \u015fekilde d\u00fc\u015f\u00fcr\u00fcr. Bu nedenle, da\u011f\u0131t\u0131k sistemlerde bu t\u00fcr senaryolar\u0131 \u00f6ng\u00f6rmek ve g\u00fcvenilir \u00e7\u00f6z\u00fcmler geli\u015ftirmek, modern yaz\u0131l\u0131m mimarilerinin temel ta\u015flar\u0131ndan biridir.<\/p>\n Bu karma\u015f\u0131k konuyu anlamak i\u00e7in \u00f6ncelikle temel yap\u0131 ta\u015flar\u0131n\u0131 netle\u015ftirmemiz gerekiyor. Veritabanlar\u0131, mesaj brokerlar\u0131 ve atomik i\u015flemler, da\u011f\u0131t\u0131k sistemlerin temel bile\u015fenleridir ve her birinin kendine \u00f6zg\u00fc rolleri ve zorluklar\u0131 bulunur.<\/p>\n Bir veritaban\u0131 (database), verileri d\u00fczenli bir \u015fekilde depolayan, y\u00f6neten ve eri\u015fim sa\u011flayan bir sistemdir. \u0130li\u015fkisel veritabanlar\u0131 (relational databases) genellikle ACID<\/strong> (Atomicity, Consistency, Isolation, Durability – Atomiklik, Tutarl\u0131l\u0131k, \u0130zolasyon, Kal\u0131c\u0131l\u0131k) prensiplerini destekler. Bu prensipler, veritaban\u0131 i\u015flemlerinin g\u00fcvenilirli\u011fini sa\u011flar:<\/p>\n Bu \u00f6zellikler sayesinde, bir veritaban\u0131na yap\u0131lan kay\u0131t i\u015flemi, \u00f6rne\u011fin bir sipari\u015fin kaydedilmesi, ya tamamen ger\u00e7ekle\u015fir ve kal\u0131c\u0131 olur ya da herhangi bir hata durumunda tamamen geri al\u0131n\u0131r, veritaban\u0131n\u0131 \u00f6nceki tutarl\u0131 durumuna d\u00f6nd\u00fcr\u00fcr. Bu, veritaban\u0131 i\u00e7indeki tutarl\u0131l\u0131\u011f\u0131 sa\u011flamak i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n Mesaj broker\u0131 (message broker), farkl\u0131 uygulamalar\u0131n veya servislerin birbirleriyle asenkron olarak ileti\u015fim kurmas\u0131n\u0131 sa\u011flayan bir ara yaz\u0131l\u0131md\u0131r (middleware). Kafka, RabbitMQ, ActiveMQ, Azure Service Bus veya AWS SQS gibi pop\u00fcler mesaj brokerlar\u0131, mesajlar\u0131 g\u00f6ndericiden (producer) al\u0131p al\u0131c\u0131ya (consumer) iletmek i\u00e7in bir arac\u0131 g\u00f6revi g\u00f6r\u00fcr. Temel i\u015flevleri \u015funlard\u0131r:<\/p>\n Mesaj brokerlar\u0131, da\u011f\u0131t\u0131k sistemlerde servisler aras\u0131 ileti\u015fimi kolayla\u015ft\u0131r\u0131r, sistemin esnekli\u011fini ve \u00f6l\u00e7eklenebilirli\u011fini art\u0131r\u0131r. Bir servis, bir olay\u0131 mesaj broker\u0131na g\u00f6ndererek i\u015fini tamamlar ve di\u011fer servislerin bu olayla ne yapaca\u011f\u0131n\u0131 dert etmez. Ancak, bu ayr\u0131\u015fma, yukar\u0131da bahsetti\u011fimiz tutars\u0131zl\u0131k sorunlar\u0131n\u0131n da ana kayna\u011f\u0131 olabilir.<\/p>\n Atomik i\u015flem kavram\u0131, tek bir mant\u0131ksal i\u015f birimi olarak kabul edilen ve ya tamamen ba\u015far\u0131l\u0131 olan ya da tamamen ba\u015far\u0131s\u0131z olan bir dizi operasyonu ifade eder. Veritabanlar\u0131 bu atomikli\u011fi kendi s\u0131n\u0131rlar\u0131 i\u00e7inde garanti ederken, da\u011f\u0131t\u0131k bir sistemde birden fazla ba\u011f\u0131ms\u0131z bile\u015feni (\u00f6rne\u011fin, bir veritaban\u0131 ve bir mesaj broker\u0131) kapsayan atomik bir i\u015flem sa\u011flamak \u00e7ok daha zordur. Bu durum, da\u011f\u0131t\u0131k i\u015flem (distributed transaction)<\/strong> olarak adland\u0131r\u0131l\u0131r.<\/p>\n Geleneksel olarak, da\u011f\u0131t\u0131k i\u015flemler i\u00e7in \u0130ki Fazl\u0131 Taahh\u00fct (Two-Phase Commit – 2PC)<\/strong> gibi protokoller geli\u015ftirilmi\u015ftir. 2PC, bir koordinat\u00f6r\u00fcn t\u00fcm kat\u0131l\u0131mc\u0131lardan (veritabanlar\u0131, mesaj kuyruklar\u0131 vb.) i\u015flemi taahh\u00fct etmeye haz\u0131r olduklar\u0131na dair onay almas\u0131n\u0131 (prepare faz\u0131) ve ard\u0131ndan t\u00fcm kat\u0131l\u0131mc\u0131lara taahh\u00fct etme veya geri alma komutunu g\u00f6ndermesini (commit faz\u0131) i\u00e7erir. Ancak 2PC, performans darbo\u011fazlar\u0131, kilitlenme riski ve tek hata noktas\u0131 (single point of failure) gibi ciddi s\u0131n\u0131rlamalara sahiptir. Bu nedenle, modern mikroservis mimarilerinde genellikle 2PC’den ka\u00e7\u0131n\u0131l\u0131r ve bunun yerine olas\u0131 tutarl\u0131l\u0131k (eventual consistency)<\/strong> modelleri tercih edilir.<\/p>\n Olas\u0131 tutarl\u0131l\u0131k, sistemdeki verilerin an\u0131nda tutarl\u0131 olmak zorunda olmad\u0131\u011f\u0131, ancak bir s\u00fcre sonra t\u00fcm kopyalar\u0131n nihayetinde ayn\u0131 de\u011fere ula\u015faca\u011f\u0131 anlam\u0131na gelir. Bu model, y\u00fcksek \u00f6l\u00e7eklenebilirlik ve kullan\u0131labilirlik sunarken, geli\u015ftiricilerin tutars\u0131zl\u0131k pencerelerini y\u00f6netmek ve bu durumlar\u0131 telafi etmek i\u00e7in \u00f6zel stratejiler geli\u015ftirmesini gerektirir. \u0130\u015fte bu noktada, veritaban\u0131 “ba\u015far\u0131l\u0131” dedi\u011finde mesaj broker\u0131n\u0131n “tekrar dene” demesi gibi durumlar, olas\u0131 tutarl\u0131l\u0131\u011f\u0131n en zorlay\u0131c\u0131 y\u00fczlerinden biri olarak kar\u015f\u0131m\u0131za \u00e7\u0131kar.<\/p>\n Da\u011f\u0131t\u0131k sistemlerde ya\u015fanan bu tutars\u0131zl\u0131klar\u0131n temelinde, iki farkl\u0131 ve ba\u011f\u0131ms\u0131z kayna\u011f\u0131n (veritaban\u0131 ve mesaj broker\u0131) tek bir mant\u0131ksal i\u015flemin par\u00e7as\u0131 olmas\u0131na ra\u011fmen, kendi i\u00e7lerinde atomikliklerini koruyup, birbirleriyle olan ileti\u015fimin atomik olmamas\u0131 yatar. Hadi bu durumu ad\u0131m ad\u0131m inceleyelim ve neden bir sorun haline geldi\u011fini g\u00f6relim.<\/p>\n Bir uygulaman\u0131n tipik bir i\u015f ak\u0131\u015f\u0131n\u0131 ele alal\u0131m:<\/p>\n Bu gibi durumlarda, mesaj broker\u0131 uygulamaya bir hata mesaj\u0131 d\u00f6ner veya ba\u011flant\u0131 kopar. Mesaj broker\u0131, “tekrar dene” veya “i\u015flem ba\u015far\u0131s\u0131z” der.<\/li>\n<\/ol>\n Yukar\u0131daki senaryonun en b\u00fcy\u00fck sonucu, sistemde olu\u015fan veri tutars\u0131zl\u0131\u011f\u0131d\u0131r<\/strong>. Veritaban\u0131nda bir ger\u00e7eklik (\u00f6rne\u011fin, yeni bir kullan\u0131c\u0131 kayd\u0131), ancak di\u011fer sistemlerde farkl\u0131 bir ger\u00e7eklik (di\u011fer servisler bu yeni kullan\u0131c\u0131dan habersiz) bulunur. Bu tutars\u0131zl\u0131klar ciddi i\u015f sorunlar\u0131na yol a\u00e7abilir:<\/p>\n M\u00fc\u015fteri, sipari\u015finin ba\u015far\u0131l\u0131 oldu\u011funu d\u00fc\u015f\u00fcn\u00fcrken, asl\u0131nda hi\u00e7bir \u015fey ilerlememi\u015ftir. Bu durum, m\u00fc\u015fteri \u015fikayetlerine, iade taleplerine ve marka itibar\u0131n\u0131n zedelenmesine neden olur.<\/li>\n Kullan\u0131c\u0131, hesab\u0131na giri\u015f yapamayabilir veya bekledi\u011fi kar\u015f\u0131lama e-postas\u0131n\u0131 almayabilir, bu da hayal k\u0131r\u0131kl\u0131\u011f\u0131 yarat\u0131r.<\/li>\n<\/ul>\n Bu t\u00fcr senaryolar, sistemin g\u00fcvenilirli\u011fini ve tutarl\u0131l\u0131\u011f\u0131n\u0131 ciddi \u015fekilde tehlikeye atar. Geli\u015ftiricilerin bu zorluklar\u0131 a\u015fmak i\u00e7in sa\u011flam ve hata toleransl\u0131 \u00e7\u00f6z\u00fcmler tasarlamas\u0131 gerekmektedir. Aksi takdirde, operasyonel ekipler s\u00fcrekli olarak manuel m\u00fcdahalelerle bu tutars\u0131zl\u0131klar\u0131 gidermeye \u00e7al\u0131\u015fmak zorunda kal\u0131r ki bu da s\u00fcrd\u00fcr\u00fclebilir bir durum de\u011fildir.<\/p>\n Da\u011f\u0131t\u0131k sistemlerin do\u011fas\u0131 gere\u011fi, birden fazla ba\u011f\u0131ms\u0131z bile\u015fenin (servisler, veritabanlar\u0131, mesaj brokerlar\u0131 vb.) ayn\u0131 anda hatas\u0131z \u00e7al\u0131\u015fmas\u0131n\u0131 beklemek ger\u00e7ek\u00e7i de\u011fildir. Bu karma\u015f\u0131kl\u0131k, g\u00fcvenilirli\u011fi sa\u011flamay\u0131 zorla\u015ft\u0131ran \u00e7e\u015fitli fakt\u00f6rlerden kaynaklan\u0131r:<\/p>\n Bu fakt\u00f6rler bir araya geldi\u011finde, da\u011f\u0131t\u0131k sistemlerde g\u00fcvenilirli\u011fi sa\u011flamak, sadece kod yazmaktan \u00f6te, sistemin t\u00fcm bile\u015fenlerinin etkile\u015fimini, olas\u0131 hata durumlar\u0131n\u0131 ve bu hatalar\u0131n nas\u0131l telafi edilece\u011fini derinlemesine anlamay\u0131 gerektiren mimari bir meydan okumaya d\u00f6n\u00fc\u015f\u00fcr.<\/p>\n Da\u011f\u0131t\u0131k sistemlerdeki bu tutars\u0131zl\u0131klar\u0131 \u00f6nlemek veya en aza indirmek i\u00e7in \u00e7e\u015fitli mimari desenler ve stratejiler geli\u015ftirilmi\u015ftir. Bu \u00e7\u00f6z\u00fcmler, sistemin hem g\u00fcvenilirli\u011fini art\u0131r\u0131r hem de hata durumlar\u0131nda daha zarif bir \u015fekilde kurtarma yapmas\u0131n\u0131 sa\u011flar.<\/p>\n Idempotentlik (idempotence), bir i\u015flemin birden fazla kez uygulanmas\u0131n\u0131n, sanki tek bir kez uygulanm\u0131\u015f gibi ayn\u0131 sonucu vermesi durumudur. Da\u011f\u0131t\u0131k sistemlerde, a\u011f hatalar\u0131 veya tekrar deneme mekanizmalar\u0131 nedeniyle ayn\u0131 mesaj\u0131n birden \u00e7ok kez g\u00f6nderilmesi yayg\u0131n bir durumdur. E\u011fer al\u0131c\u0131 servisler idempotent de\u011filse, ayn\u0131 mesaj\u0131 birden \u00e7ok kez i\u015fleyerek veri tekrar\u0131na, hatal\u0131 durumlara veya yanl\u0131\u015f hesaplamalara yol a\u00e7abilirler. \u00d6rne\u011fin, bir \u00f6deme i\u015flemi idempotent de\u011filse, ayn\u0131 sipari\u015f i\u00e7in birden \u00e7ok kez para \u00e7ekilebilir.<\/p>\n Idempotentli\u011fi sa\u011flamak i\u00e7in genellikle benzersiz bir i\u015flem kimli\u011fi (transaction ID) kullan\u0131l\u0131r. Al\u0131c\u0131 servis, bir mesaj\u0131 i\u015flerken \u00f6nce bu kimli\u011fi kontrol eder. E\u011fer bu kimli\u011fe sahip bir mesaj daha \u00f6nce i\u015flenmi\u015fse, mesaj\u0131 tekrar i\u015flemez veya sadece ilk i\u015flemin sonucunu d\u00f6ner. Bu, \u00f6zellikle mesaj broker\u0131na mesaj g\u00f6nderme i\u015fleminin ba\u015far\u0131s\u0131z olup, daha sonra tekrar denendi\u011fi durumlarda \u00e7ok \u00f6nemlidir.<\/p>\n Bu \u00f6rnekte, Outbox deseni, veritaban\u0131 i\u015flemi ile mesaj g\u00f6nderme i\u015flemini atomik hale getirmek i\u00e7in kullan\u0131lan en yayg\u0131n ve etkili desenlerden biridir. Temel fikir \u015fudur: mesaj\u0131 do\u011frudan mesaj broker\u0131na g\u00f6ndermek yerine, veritaban\u0131 i\u015flemiyle birlikte ayn\u0131 veritaban\u0131 i\u015flemi i\u00e7inde bir “outbox” (giden kutusu) tablosuna kaydedilir.<\/p>\n Bu desenin en b\u00fcy\u00fck avantaj\u0131, veritaban\u0131 ve mesaj g\u00f6nderme aras\u0131nda atomikli\u011fi sa\u011flamas\u0131d\u0131r. Mesaj broker\u0131 ge\u00e7ici olarak kullan\u0131lamaz olsa bile, mesaj outbox tablosunda g\u00fcvende bekler ve broker tekrar kullan\u0131labilir oldu\u011funda g\u00f6nderilir. Ayr\u0131ca, mesaj r\u00f6lesi idempotent bir \u015fekilde \u00e7al\u0131\u015facak \u015fekilde tasarlanabilir, b\u00f6ylece ayn\u0131 mesaj\u0131n birden \u00e7ok kez g\u00f6nderilmesi durumunda bile sorun ya\u015fanmaz.<\/p>\n Yukar\u0131daki kod \u00f6rne\u011finde, hem sipari\u015f kayd\u0131 hem de outbox mesaj kayd\u0131 tek bir veritaban\u0131 i\u015flemi i\u00e7inde ger\u00e7ekle\u015fir. Bu, veritaban\u0131nda bir sipari\u015f varsa, outbox’ta da o sipari\u015fin olay mesaj\u0131n\u0131n mutlaka olaca\u011f\u0131n\u0131 garanti eder.<\/p>\n Saga deseni, birden fazla yerel i\u015flemden (local transactions) olu\u015fan uzun s\u00fcreli, da\u011f\u0131t\u0131k i\u015flemlerin y\u00f6netimi i\u00e7in kullan\u0131l\u0131r. Her yerel i\u015flem kendi veritaban\u0131 i\u00e7inde atomiktir, ancak t\u00fcm saga genelinde atomiklik, telafi edici i\u015flemler (compensating transactions) ile sa\u011flan\u0131r. Bir ad\u0131m ba\u015far\u0131s\u0131z olursa, \u00f6nceki ad\u0131mlar\u0131n etkilerini geri almak i\u00e7in telafi edici i\u015flemler tetiklenir.<\/p>\n Saga’lar iki \u015fekilde uygulanabilir:<\/p>\n Saga deseni, \u00f6zellikle karma\u015f\u0131k i\u015f ak\u0131\u015flar\u0131na sahip, birden fazla mikroservisi ve veritaban\u0131n\u0131 i\u00e7eren senaryolarda kullan\u0131l\u0131r. \u00d6rne\u011fin, bir rezervasyon sistemi, hem otel rezervasyonu, hem u\u00e7ak bileti al\u0131m\u0131, hem de ara\u00e7 kiralama gibi ad\u0131mlar\u0131 i\u00e7eren bir saga ile y\u00f6netilebilir.<\/p>\n Ge\u00e7ici a\u011f hatalar\u0131 veya servislerin k\u0131sa s\u00fcreli kullan\u0131lamazl\u0131\u011f\u0131 durumlar\u0131nda, i\u015flemleri tekrar denemek (retry) ak\u0131ll\u0131ca bir stratejidir. Ancak, tekrar denemeleri do\u011fru bir \u015fekilde y\u00f6netmek \u00f6nemlidir:<\/p>\n Hi\u00e7bir \u00e7\u00f6z\u00fcm %100 kusursuz de\u011fildir. Bu nedenle, sistemdeki olas\u0131 tutars\u0131zl\u0131klar\u0131 ve hatalar\u0131 erken tespit etmek i\u00e7in g\u00fc\u00e7l\u00fc izleme (monitoring) ve uyar\u0131 (alerting) sistemleri kurmak hayati \u00f6neme sahiptir. Mesaj kuyruklar\u0131nda biriken mesaj say\u0131lar\u0131, ba\u015far\u0131s\u0131z mesaj teslimatlar\u0131, outbox tablosunda uzun s\u00fcre i\u015flenmeyi bekleyen mesajlar gibi metrikler izlenmelidir. Anormal durumlar alg\u0131land\u0131\u011f\u0131nda, ilgili ekiplere otomatik uyar\u0131lar g\u00f6nderilmelidir. Bu, sorunlara h\u0131zl\u0131ca m\u00fcdahale edilmesini ve potansiyel veri tutars\u0131zl\u0131klar\u0131n\u0131n b\u00fcy\u00fcmeden giderilmesini sa\u011flar.<\/p>\n Bu \u00e7\u00f6z\u00fcm y\u00f6ntemleri, tek ba\u015f\u0131na veya kombinasyon halinde kullan\u0131larak da\u011f\u0131t\u0131k sistemlerdeki g\u00fcvenilirlik ve tutarl\u0131l\u0131k sorunlar\u0131n\u0131n \u00fcstesinden gelmeye yard\u0131mc\u0131 olur. Do\u011fru deseni se\u00e7mek, uygulaman\u0131n \u00f6zel gereksinimlerine, \u00f6l\u00e7eklenebilirlik ihtiya\u00e7lar\u0131na ve hata tolerans\u0131 beklentilerine ba\u011fl\u0131d\u0131r.<\/p>\n Teorik bilgileri somutla\u015ft\u0131rmak i\u00e7in, ger\u00e7ek bir e-ticaret platformunun sipari\u015f i\u015fleme s\u00fcrecindeki tutarl\u0131l\u0131k sorunlar\u0131n\u0131 ve bu sorunlara uygulanan \u00e7\u00f6z\u00fcmleri inceleyelim. Bu vaka analizi, “Veritaban\u0131 ‘Ba\u015far\u0131l\u0131’ Dedi, Mesaj Broker\u0131 ‘Tekrar Dene'” senaryosunun pratikte nas\u0131l ortaya \u00e7\u0131kt\u0131\u011f\u0131n\u0131 ve Outbox deseni gibi yakla\u015f\u0131mlar\u0131n nas\u0131l bir kurtar\u0131c\u0131 oldu\u011funu g\u00f6sterecektir.<\/p>\n Bir e-ticaret platformunda, m\u00fc\u015fteri bir \u00fcr\u00fcn sepetini onaylay\u0131p “Sipari\u015f Ver” butonuna t\u0131klad\u0131\u011f\u0131nda a\u015fa\u011f\u0131daki ad\u0131mlar beklenir:<\/p>\n Bu ak\u0131\u015fta, Sipari\u015f Servisi, veritaban\u0131na sipari\u015fi kaydettikten sonra, di\u011fer servisleri bilgilendirmek i\u00e7in bir mesaj broker\u0131 (\u00f6rne\u011fin, Kafka) kullan\u0131r. Yani, Sipari\u015f Servisi, veritaban\u0131na kayd\u0131 yapt\u0131ktan sonra Bir g\u00fcn, platformda yo\u011fun bir kampanya d\u00f6nemi ya\u015fan\u0131yor. Milyonlarca sipari\u015f ayn\u0131 anda i\u015flenmeye \u00e7al\u0131\u015f\u0131l\u0131yor. Bu yo\u011funluk s\u0131ras\u0131nda, Sipari\u015f Servisi veritaban\u0131na yeni sipari\u015fleri ba\u015far\u0131yla kaydediyor. Ancak, tam bu s\u0131rada Kafka k\u00fcmesinde ge\u00e7ici bir a\u011f kesintisi veya broker sunucular\u0131ndan birinin a\u015f\u0131r\u0131 y\u00fcklenmesi ya\u015fan\u0131yor. Sipari\u015f Servisi, Sonu\u00e7:<\/strong> Sipari\u015f veritaban\u0131nda “olu\u015fturuldu” durumunda, ancak Kafka’ya mesaj g\u00f6nderilemedi\u011fi i\u00e7in \u00d6deme Servisi \u00f6deme i\u015flemini ba\u015flatam\u0131yor, Envanter Servisi stoklar\u0131 d\u00fc\u015f\u00fcremiyor ve m\u00fc\u015fteriye onay e-postas\u0131 gitmiyor. M\u00fc\u015fteriler, sipari\u015flerinin “beklemede” kald\u0131\u011f\u0131n\u0131 g\u00f6r\u00fcyor ve \u015fikayetler ya\u011fmaya ba\u015fl\u0131yor. Operasyonel ekip, veritaban\u0131nda olan sipari\u015flerin neden i\u015flenmedi\u011fini anlamaya \u00e7al\u0131\u015f\u0131rken b\u00fcy\u00fck bir karma\u015fa ya\u015f\u0131yor.<\/p>\n Bu t\u00fcr bir felaketi \u00f6nlemek i\u00e7in e-ticaret platformu, Sipari\u015f Servisi’ne Outbox Deseni’ni<\/strong> entegre etmeye karar verdi. Ayr\u0131ca, \u00d6deme Servisi gibi kritik servisler i\u00e7in idempotent i\u015flem<\/strong> yetene\u011fini de ekledi.<\/p>\n Bu sayede, veritaban\u0131nda sipari\u015f varsa, outbox tablosunda da o sipari\u015fin olay\u0131 mutlaka bulunur. Atomiklik garanti alt\u0131na al\u0131nm\u0131\u015ft\u0131r.<\/p>\n<\/li>\n \u00d6deme Servisi, Bu \u00e7\u00f6z\u00fcm sayesinde, e-ticaret platformu a\u015fa\u011f\u0131daki \u00f6nemli kazan\u0131mlar\u0131 elde etti:<\/p>\n Bu vaka analizi, Outbox deseni ve idempotent i\u015flemlerin, da\u011f\u0131t\u0131k sistemlerdeki “veritaban\u0131 ba\u015far\u0131l\u0131, mesaj broker\u0131 tekrar dene” sorununu \u00e7\u00f6zmek i\u00e7in ne kadar kritik oldu\u011funu a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Bu desenler, hem geli\u015ftiricilerin y\u00fck\u00fcn\u00fc azalt\u0131r hem de i\u015f s\u00fcre\u00e7lerinin kesintisiz devaml\u0131l\u0131\u011f\u0131n\u0131 sa\u011flar.<\/p>\n Yukar\u0131da ele ald\u0131\u011f\u0131m\u0131z \u00e7\u00f6z\u00fcmler, bir\u00e7ok temel tutarl\u0131l\u0131k sorununu giderse de, da\u011f\u0131t\u0131k sistemlerin karma\u015f\u0131kl\u0131\u011f\u0131 bazen daha ileri d\u00fczey stratejiler gerektirebilir. \u00d6zellikle b\u00fcy\u00fck \u00f6l\u00e7ekli ve y\u00fcksek performansl\u0131 sistemlerde, bu ipu\u00e7lar\u0131 kritik rol oynar.<\/p>\n Mikroservis mimarilerinde bir kullan\u0131c\u0131 iste\u011fi, birden fazla servisten ge\u00e7ebilir. Her servis kendi i\u00e7indeki i\u015flemleri izleyebilirken, bir iste\u011fin t\u00fcm sistem boyunca nas\u0131l ilerledi\u011fini anlamak zorla\u015f\u0131r. \u0130\u015fte burada da\u011f\u0131t\u0131k izleme (distributed tracing)<\/strong> devreye girer. Zipkin, Jaeger veya OpenTelemetry gibi ara\u00e7lar, bir iste\u011fin ba\u015flang\u0131c\u0131ndan biti\u015fine kadar t\u00fcm servisler aras\u0131ndaki yolculu\u011funu takip etmeyi sa\u011flar.<\/p>\n Her servis, ald\u0131\u011f\u0131 iste\u011fe benzersiz bir “izleme kimli\u011fi” (trace ID) ekler ve bu kimli\u011fi sonraki servislere iletir. Bu sayede, “Veritaban\u0131 ‘Ba\u015far\u0131l\u0131’ Dedi, Mesaj Broker\u0131 ‘Tekrar Dene'” gibi bir sorun ya\u015fand\u0131\u011f\u0131nda, hangi servisin ne zaman hata verdi\u011fini, mesaj\u0131n nerede tak\u0131ld\u0131\u011f\u0131n\u0131 veya gecikti\u011fini kolayca tespit edebiliriz. \u00d6rne\u011fin, bir sipari\u015fin veritaban\u0131na kaydedildi\u011fi ancak mesaj broker\u0131na g\u00f6nderilemedi\u011fi bir durumda, izleme ara\u00e7lar\u0131 sayesinde, Sipari\u015f Servisi’nin Kafka’ya mesaj g\u00f6nderme \u00e7a\u011fr\u0131s\u0131n\u0131n ba\u015far\u0131s\u0131z oldu\u011funu ve bunun nedenini (a\u011f hatas\u0131, Kafka’n\u0131n yan\u0131t vermemesi vb.) an\u0131nda g\u00f6rebiliriz. Bu, sorun giderme s\u00fcresini (MTTR – Mean Time To Recovery) \u00f6nemli \u00f6l\u00e7\u00fcde k\u0131salt\u0131r ve sistemin genel sa\u011fl\u0131\u011f\u0131 hakk\u0131nda derinlemesine bilgi sa\u011flar.<\/p>\n Outbox deseni, uygulama koduna ba\u011f\u0131ml\u0131 bir \u00e7\u00f6z\u00fcmd\u00fcr. Alternatif olarak, baz\u0131 durumlarda veritaban\u0131n\u0131n i\u015flem g\u00fcnl\u00fc\u011f\u00fcn\u00fc (transaction log) kullanarak de\u011fi\u015fiklikleri yakalamak (Change Data Capture – CDC) daha uygun olabilir. Debezium, Maxwell veya Striim gibi CDC ara\u00e7lar\u0131, veritaban\u0131 i\u015flem g\u00fcnl\u00fc\u011f\u00fcn\u00fc izleyerek (\u00f6rne\u011fin, PostgreSQL’in WAL’\u0131, MySQL’in binlog’u) veritaban\u0131nda ger\u00e7ekle\u015fen t\u00fcm de\u011fi\u015fiklikleri ger\u00e7ek zamanl\u0131 olarak yakalar ve bu de\u011fi\u015fiklikleri bir mesaj broker\u0131na (genellikle Kafka’ya) olay olarak yay\u0131mlar.<\/p>\n CDC’nin avantaj\u0131, uygulama koduna herhangi bir de\u011fi\u015fiklik yapmadan, veritaban\u0131ndaki her de\u011fi\u015fikli\u011fin otomatik olarak bir olaya d\u00f6n\u00fc\u015ft\u00fcr\u00fclmesidir. Bu, outbox tablosu y\u00f6netimi ve mesaj r\u00f6lesi servisi geli\u015ftirme y\u00fck\u00fcn\u00fc ortadan kald\u0131r\u0131r. Veritaban\u0131 i\u015flemi ba\u015far\u0131l\u0131 oldu\u011funda, bu de\u011fi\u015fiklik otomatik olarak i\u015flem g\u00fcnl\u00fc\u011f\u00fcne yaz\u0131l\u0131r ve CDC arac\u0131 taraf\u0131ndan hemen alg\u0131lan\u0131r. Bu yakla\u015f\u0131m, veritaban\u0131 ve olay yay\u0131mlama aras\u0131ndaki atomikli\u011fi do\u011fal olarak sa\u011flar, \u00e7\u00fcnk\u00fc her ikisi de veritaban\u0131n\u0131n kendi atomik i\u015flem garantileri alt\u0131ndad\u0131r. Ancak, CDC ara\u00e7lar\u0131n\u0131n kurulumu ve y\u00f6netimi ek bir karma\u015f\u0131kl\u0131k getirebilir ve her veritaban\u0131 i\u00e7in uygun olmayabilir.<\/p>\n Event Sourcing (Olay Kaynaklama)<\/strong>, bir uygulaman\u0131n mevcut durumunu do\u011frudan depolamak yerine, bu duruma yol a\u00e7an t\u00fcm olaylar\u0131 (de\u011fi\u015fiklikleri) bir olay deposunda (event store) s\u0131ral\u0131 bir \u015fekilde kaydetme desenidir. Uygulaman\u0131n mevcut durumu, bu olay ak\u0131\u015f\u0131n\u0131n yeniden oynat\u0131lmas\u0131yla (replay) elde edilir. Her olay, uygulaman\u0131n durumunda yap\u0131lan bir de\u011fi\u015fikli\u011fi temsil eder ve de\u011fi\u015ftirilemezdir (immutable).<\/p>\n Olay Kaynaklama, do\u011fas\u0131 gere\u011fi “Veritaban\u0131 ‘Ba\u015far\u0131l\u0131’ Dedi, Mesaj Broker\u0131 ‘Tekrar Dene'” sorununu farkl\u0131 bir \u015fekilde ele al\u0131r. Burada, veritaban\u0131 kayd\u0131 asl\u0131nda bir olay\u0131n olay deposuna kaydedilmesidir. Olay deposu, ayn\u0131 zamanda bir mesaj broker\u0131 gibi davranabilir veya bir CDC arac\u0131yla entegre edilebilir. Bir olay olay deposuna ba\u015far\u0131yla kaydedildi\u011finde, bu olay di\u011fer servisler taraf\u0131ndan t\u00fcketilebilir hale gelir. Bu, veritaban\u0131 ve mesaj g\u00f6nderme aras\u0131nda atomikli\u011fi do\u011fal olarak sa\u011flar, \u00e7\u00fcnk\u00fc olay deposuna yazma i\u015flemi hem kal\u0131c\u0131 depolamay\u0131 hem de olay yay\u0131mlamay\u0131 temsil eder.<\/p>\n Event Sourcing’in faydalar\u0131 aras\u0131nda, denetlenebilirlik (auditing), zamana g\u00f6re geri sarma (time travel debugging), karma\u015f\u0131k i\u015f mant\u0131klar\u0131n\u0131 modelleme ve olas\u0131 tutarl\u0131l\u0131kla do\u011fal uyum yer al\u0131r. Ancak, bu desenin uygulanmas\u0131, geleneksel CRUD (Create, Read, Update, Delete) tabanl\u0131 mimarilere g\u00f6re daha karma\u015f\u0131kt\u0131r ve \u00f6zel ara\u00e7lar gerektirebilir.<\/p>\n Bu geli\u015fmi\u015f stratejiler, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k da\u011f\u0131t\u0131k sistemlerde, tutarl\u0131l\u0131k, hata tolerans\u0131 ve izlenebilirlik ihtiya\u00e7lar\u0131n\u0131 kar\u015f\u0131lamak i\u00e7in g\u00fc\u00e7l\u00fc ara\u00e7lar sunar. Do\u011fru stratejiyi se\u00e7mek, sistemin mimarisine, mevcut altyap\u0131s\u0131na ve i\u015f gereksinimlerine ba\u011fl\u0131d\u0131r.<\/p>\n Genel olarak, Outbox Deseni (Transactional Outbox Pattern)<\/strong>, veritaban\u0131 ve mesaj broker\u0131 aras\u0131nda atomikli\u011fi sa\u011flamak i\u00e7in en pratik ve yayg\u0131n olarak kabul g\u00f6rm\u00fc\u015f yoldur. Bu desen, mesaj\u0131n veritaban\u0131 i\u015flemiyle birlikte ayn\u0131 i\u015flem i\u00e7inde bir outbox tablosuna kaydedilmesini garanti eder. Daha sonra ayr\u0131 bir servis, bu outbox tablosundan mesajlar\u0131 okuyarak mesaj broker\u0131na iletir. Bu sayede, veritaban\u0131nda bir kay\u0131t varsa, o kayda ait olay\u0131n er ya da ge\u00e7 broker’a ula\u015fmas\u0131 garanti edilir.<\/p>\n Evet, Outbox deseni, ek bir veritaban\u0131 yazma i\u015flemi ve outbox tablosunu periyodik olarak sorgulayan bir mesaj r\u00f6lesi servisi gerektirdi\u011finden belirli bir performans y\u00fck\u00fc getirebilir. Ancak bu y\u00fck genellikle y\u00f6netilebilir d\u00fczeydedir. Performans sorunlar\u0131n\u0131 azaltmak i\u00e7in \u015funlar yap\u0131labilir:<\/p>\n Do\u011fru uyguland\u0131\u011f\u0131nda, Outbox deseninin getirdi\u011fi performans maliyeti, sa\u011flad\u0131\u011f\u0131 tutarl\u0131l\u0131k ve g\u00fcvenilirlik avantajlar\u0131 kar\u015f\u0131s\u0131nda genellikle kabul edilebilir d\u00fczeydedir.<\/p>\n Saga deseni, birden fazla ba\u011f\u0131ms\u0131z servisi ve onlar\u0131n yerel veritaban\u0131 i\u015flemlerini kapsayan uzun s\u00fcreli, karma\u015f\u0131k da\u011f\u0131t\u0131k i\u015f ak\u0131\u015flar\u0131 i\u00e7in kullan\u0131lmal\u0131d\u0131r. \u00d6rne\u011fin, bir e-ticaret sitesinde sipari\u015fin al\u0131nmas\u0131, \u00f6demenin i\u015flenmesi, envanterin g\u00fcncellenmesi ve kargonun ayarlanmas\u0131 gibi ad\u0131mlar\u0131n her birinin ayr\u0131 bir servis taraf\u0131ndan y\u00f6netildi\u011fi ve bu ad\u0131mlar\u0131n birinin ba\u015far\u0131s\u0131z olmas\u0131 durumunda \u00f6nceki ad\u0131mlar\u0131n telafi edilmesi gereken senaryolarda Saga deseni \u00e7ok uygundur. Basit, tek ad\u0131ml\u0131 olay yay\u0131mlama senaryolar\u0131 i\u00e7in Outbox deseni genellikle yeterlidir.<\/p>\n Dead Letter Queue (DLQ – \u00d6l\u00fc Mektup Kuyru\u011fu), mesaj brokerlar\u0131nda, belirli bir say\u0131da tekrar denemeye ra\u011fmen ba\u015far\u0131yla i\u015flenemeyen veya ge\u00e7ersiz oldu\u011fu tespit edilen mesajlar\u0131n g\u00f6nderildi\u011fi \u00f6zel bir kuyruktur. DLQ’nun temel amac\u0131, i\u015flenemeyen mesajlar\u0131n ana kuyru\u011fu t\u0131kamas\u0131n\u0131 \u00f6nlemek ve bu mesajlar\u0131 ayr\u0131 bir yerde toplayarak manuel inceleme, hata ay\u0131klama veya yeniden i\u015fleme imkan\u0131 sunmakt\u0131r. Bu sayede, sistemin genel i\u015fleyi\u015fi aksamazken, ba\u015far\u0131s\u0131z mesajlar\u0131n nedenleri ara\u015ft\u0131r\u0131labilir ve gerekti\u011finde d\u00fczeltilebilir.<\/p>\n Idempotent i\u015flemler, da\u011f\u0131t\u0131k sistemlerdeki g\u00fcvenilirli\u011fin temel ta\u015flar\u0131ndan biridir. A\u011f hatalar\u0131, tekrar deneme mekanizmalar\u0131 veya mesaj brokerlar\u0131n\u0131n “en az bir kez teslimat” (at-least-once delivery) garantisi nedeniyle ayn\u0131 mesaj\u0131n al\u0131c\u0131 servise birden \u00e7ok kez ula\u015fmas\u0131 yayg\u0131n bir durumdur. E\u011fer bir i\u015flem idempotent de\u011filse, ayn\u0131 mesaj\u0131n birden \u00e7ok kez i\u015flenmesi, veri tekrar\u0131na, yanl\u0131\u015f durumlara (\u00f6rne\u011fin, ayn\u0131 \u00f6demenin iki kez \u00e7ekilmesi, envanterin birden \u00e7ok kez d\u00fc\u015f\u00fclmesi) veya i\u015f mant\u0131\u011f\u0131 hatalar\u0131na yol a\u00e7abilir. Idempotentlik, bir i\u015flemin birden \u00e7ok kez uygulanmas\u0131n\u0131n ayn\u0131 sonucu vermesini sa\u011flayarak bu t\u00fcr sorunlar\u0131 \u00f6nler ve sistemin tutarl\u0131l\u0131\u011f\u0131n\u0131 korur.<\/p>\n Modern yaz\u0131l\u0131m mimarileri, \u00f6zellikle mikroservislerin yayg\u0131nla\u015fmas\u0131yla birlikte, sistemler aras\u0131ndaki ileti\u015fim ve veri tutarl\u0131l\u0131\u011f\u0131 konusunda \u00f6nemli zorluklar\u0131 beraberinde getiriyor. “Veritaban\u0131 ‘Ba\u015far\u0131l\u0131’ Dedi, Mesaj Broker\u0131 ‘Tekrar Dene'” senaryosu, da\u011f\u0131t\u0131k sistemlerin do\u011fas\u0131nda var olan bu tutars\u0131zl\u0131k potansiyelinin en \u00e7arp\u0131c\u0131 \u00f6rneklerinden biridir. Bu durum, veritaban\u0131 d\u00fczeyinde atomiklik sa\u011flan\u0131rken, farkl\u0131 sistemler aras\u0131ndaki ileti\u015fimin atomik olmamas\u0131ndan kaynaklan\u0131r ve ciddi i\u015f s\u00fcre\u00e7leri aksakl\u0131klar\u0131na yol a\u00e7abilir.<\/p>\n Ancak, bu zorluklar a\u015f\u0131lamaz de\u011fildir. Outbox deseni, Saga deseni, idempotent i\u015flemler, sa\u011flam tekrar deneme mekanizmalar\u0131 ve geli\u015fmi\u015f izleme ara\u00e7lar\u0131 gibi mimari desenler ve stratejiler, bu t\u00fcr sorunlar\u0131 \u00e7\u00f6zmek i\u00e7in g\u00fc\u00e7l\u00fc bir ara\u00e7 seti sunar. Outbox deseni, veritaban\u0131 i\u015flemi ile mesaj g\u00f6nderme i\u015flemini atomik hale getirerek veri tutarl\u0131l\u0131\u011f\u0131n\u0131 garanti alt\u0131na al\u0131rken, idempotentlik ayn\u0131 mesaj\u0131n birden \u00e7ok kez i\u015flenmesi durumunda bile sistemin do\u011fru \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar. Saga deseni ise, daha karma\u015f\u0131k ve uzun s\u00fcreli da\u011f\u0131t\u0131k i\u015flemlerin g\u00fcvenilir bir \u015fekilde y\u00f6netilmesine olanak tan\u0131r.<\/p>\n G\u00fcvenilir da\u011f\u0131t\u0131k sistemler in\u015fa etmek, sadece kod yazmakla bitmez; ayn\u0131 zamanda sistemin t\u00fcm bile\u015fenlerinin etkile\u015fimini, olas\u0131 hata durumlar\u0131n\u0131 ve bu hatalar\u0131n nas\u0131l telafi edilece\u011fini derinlemesine anlamay\u0131 gerektirir. Geli\u015ftiricilerin bu desenleri ve yakla\u015f\u0131mlar\u0131 kavramas\u0131 ve kendi projelerine uygun bir \u015fekilde uygulamas\u0131 kritik \u00f6neme sahiptir. Unutmayal\u0131m ki, bir sistemin ger\u00e7ek g\u00fcc\u00fc, sorunsuz \u00e7al\u0131\u015ft\u0131\u011f\u0131 zamanlarda de\u011fil, beklenmedik hatalarla kar\u015f\u0131la\u015ft\u0131\u011f\u0131nda nas\u0131l tepki verdi\u011finde ortaya \u00e7\u0131kar. Bu stratejiler sayesinde, daha esnek, \u00f6l\u00e7eklenebilir ve hata toleransl\u0131 uygulamalar geli\u015ftirerek kullan\u0131c\u0131lar\u0131m\u0131za kesintisiz bir deneyim sunabiliriz.<\/p>\n #Teknoloji #WebGeli\u015ftirme #Mikroservis #Da\u011f\u0131t\u0131kSistemler #VeriTutarl\u0131l\u0131\u011f\u0131<\/p>\nOrderCreated<\/code> (Sipari\u015f Olu\u015fturuldu) olay\u0131n\u0131 Kafka veya RabbitMQ gibi bir mesaj broker\u0131na yay\u0131mlar. Di\u011fer servisler bu olay\u0131 dinleyerek kendi i\u015f mant\u0131klar\u0131n\u0131 y\u00fcr\u00fct\u00fcrler.<\/p>\nTemel Kavramlar: Veritaban\u0131, Mesaj Broker\u0131 ve Atomik \u0130\u015flemler Nedir?<\/h2>\n
Veritaban\u0131 \u0130\u015flemleri ve ACID \u00d6zellikleri<\/h3>\n
\n
Mesaj Brokerlar\u0131 ve Asenkron \u0130leti\u015fim<\/h3>\n
\n
Atomik \u0130\u015flemler ve Da\u011f\u0131t\u0131k Sistemlerdeki Zorluklar\u0131<\/h3>\n
Problem Senaryosu: Veritaban\u0131 Ba\u015far\u0131s\u0131 ve Mesaj Broker\u0131 Hatas\u0131 Nas\u0131l M\u00fcmk\u00fcn Olur?<\/h2>\n
Tipik \u0130\u015f Ak\u0131\u015f\u0131 ve Hata Noktas\u0131<\/h3>\n
\n
UserCreatedEvent<\/code> (Kullan\u0131c\u0131 Olu\u015fturuldu Olay\u0131) veya OrderPlacedEvent<\/code> (Sipari\u015f Verildi Olay\u0131) gibi bir olay mesaj broker\u0131na g\u00f6nderilmek \u00fczere haz\u0131rlan\u0131r.<\/li>\n\n
Bu Durum Ne Gibi Sorunlara Yol A\u00e7ar?<\/h3>\n
\n
OrderPlacedEvent<\/code> mesaj broker\u0131na g\u00f6nderilemedi. Sonu\u00e7 olarak:\n\n
UserCreatedEvent<\/code> mesaj\u0131 broker’a ula\u015famad\u0131. Bu durumda:\n\n
Sorunun K\u00f6kenleri: Da\u011f\u0131t\u0131k Sistemlerde G\u00fcvenilirlik Neden Zorludur?<\/h3>\n
\n
\u00c7\u00f6z\u00fcm Y\u00f6ntemleri: Bu Tutars\u0131zl\u0131klar\u0131 Nas\u0131l \u00d6nleyebiliriz?<\/h2>\n
Idempotent \u0130\u015flemler: Ayn\u0131 \u0130\u015flemin Tekrar\u0131 Sorun Yaratmas\u0131n<\/h3>\n
\n\/\/ Pseudocode: Idempotent \u00d6deme \u0130\u015flemi\nfunction ProcessPayment(transactionId, orderId, amount) {\n if (PaymentService.IsTransactionProcessed(transactionId)) {\n console.log(\"Bu i\u015flem zaten i\u015flenmi\u015f: \" + transactionId);\n return; \/\/ \u0130\u015flemi tekrar yapma\n }\n\n \/\/ \u00d6deme i\u015flemini ger\u00e7ekle\u015ftir\n PaymentGateway.Charge(orderId, amount);\n\n \/\/ \u0130\u015flemi i\u015flenmi\u015f olarak i\u015faretle\n PaymentService.MarkTransactionAsProcessed(transactionId);\n console.log(\"\u00d6deme ba\u015far\u0131yla i\u015flendi: \" + transactionId);\n}\n <\/code><\/pre>\n<\/div>\ntransactionId<\/code> sayesinde ayn\u0131 \u00f6deme iste\u011fi birden fazla kez gelse bile, \u00f6deme sadece bir kez i\u015flenir.<\/p>\nOutbox Deseni (Transactional Outbox Pattern): Atomikli\u011fi Garanti Alt\u0131na Almak<\/h3>\n
Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h4>\n
\n
OutboxMessages<\/code> tablosuna kaydeder. Bu iki kay\u0131t (ana veri ve outbox mesaj\u0131) ayn\u0131 veritaban\u0131 i\u015flemi i\u00e7inde oldu\u011fu i\u00e7in, ya ikisi de ba\u015far\u0131l\u0131 olur ya da ikisi de geri al\u0131n\u0131r. Bu, atomikli\u011fi garanti eder.<\/li>\nOutboxMessages<\/code> tablosunu tarar. \u0130\u015flenmemi\u015f mesajlar\u0131 bulur.<\/li>\n\n-- \u00d6rnek Outbox tablosu yap\u0131s\u0131\nCREATE TABLE OutboxMessages (\n Id UUID PRIMARY KEY,\n OccurredOn TIMESTAMP NOT NULL,\n TypeName VARCHAR(255) NOT NULL,\n Payload TEXT NOT NULL, -- JSON format\u0131nda mesaj i\u00e7eri\u011fi\n ProcessedOn TIMESTAMP,\n Attempts INT DEFAULT 0\n);\n\n-- Veritaban\u0131 i\u015flemi ve Outbox kayd\u0131 (pseudo-code)\nBEGIN TRANSACTION; -- Veritaban\u0131 i\u015flemi ba\u015flat\n\nINSERT INTO Orders (Id, CustomerId, Amount, Status)\nVALUES ('order-123', 'customer-456', 100.00, 'Pending');\n\nINSERT INTO OutboxMessages (Id, OccurredOn, TypeName, Payload)\nVALUES ('message-789', NOW(), 'OrderCreatedEvent', '{\"orderId\": \"order-123\", \"customerId\": \"customer-456\", \"amount\": 100.00}');\n\nCOMMIT; -- Veritaban\u0131 i\u015flemi taahh\u00fct et\n <\/code><\/pre>\n<\/div>\nSaga Deseni (Saga Pattern): Uzun S\u00fcreli Da\u011f\u0131t\u0131k \u0130\u015flemler \u0130\u00e7in<\/h3>\n
\n
Tekrar Deneme Mekanizmalar\u0131 ve Geri \u00c7ekilme Stratejileri (Retry Mechanisms & Backoff Strategies)<\/h3>\n
\n
\u0130zleme ve Uyar\u0131 (Monitoring & Alerting): Tutars\u0131zl\u0131klar\u0131 Erken Tespit Etme<\/h3>\n
Vaka Analizi: Ger\u00e7ek D\u00fcnya Uygulamalar\u0131nda Tutarl\u0131l\u0131k Sorunlar\u0131 ve \u00c7\u00f6z\u00fcmleri<\/h2>\n
Senaryo: E-ticaret Platformunda Sipari\u015f \u0130\u015fleme<\/h3>\n
\n
OrderCreatedEvent<\/code> (Sipari\u015f Olu\u015fturuldu Olay\u0131) mesaj\u0131n\u0131 Kafka’ya yay\u0131mlar. \u00d6deme, Envanter, E-posta ve Kargo servisleri bu olaya abone olmu\u015ftur ve kendi i\u015f mant\u0131klar\u0131n\u0131 bu olay\u0131 ald\u0131klar\u0131nda tetiklerler.<\/p>\nProblem Ortaya \u00c7\u0131k\u0131yor: Veritaban\u0131 Kayd\u0131 Ba\u015far\u0131l\u0131, Kafka Hatas\u0131<\/h3>\n
OrderCreatedEvent<\/code> mesaj\u0131n\u0131 Kafka’ya g\u00f6ndermeye \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, Kafka’dan bir hata yan\u0131t\u0131 al\u0131yor veya ba\u011flant\u0131 kopuyor.<\/p>\n\u00c7\u00f6z\u00fcm Uygulamas\u0131: Outbox Deseni ve Idempotent \u0130\u015flemler<\/h3>\n
Outbox Deseni Uygulamas\u0131:<\/h4>\n
\n
OutboxMessages<\/code> ad\u0131nda yeni bir tablo eklendi. Bu tablo, g\u00f6nderilmesi gereken t\u00fcm olay mesajlar\u0131n\u0131 depolayacak.<\/li>\nOrderCreatedEvent<\/code> mesaj\u0131n\u0131 da OutboxMessages<\/code> tablosuna kaydeder.\n\n BEGIN TRANSACTION;\n\n INSERT INTO Orders (Id, CustomerId, Amount, Status)\n VALUES ('order-456', 'customer-789', 250.00, 'Pending');\n\n INSERT INTO OutboxMessages (Id, OccurredOn, TypeName, Payload, ProcessedOn, Attempts)\n VALUES ('event-101', NOW(), 'OrderCreatedEvent', '{\"orderId\": \"order-456\", \"customerId\": \"customer-789\"}', NULL, 0);\n\n COMMIT;\n <\/code><\/pre>\n<\/p><\/div>\nOutboxMessages<\/code> tablosunu sorgular ve ProcessedOn<\/code> alan\u0131 NULL<\/code> olan mesajlar\u0131 (yani hen\u00fcz i\u015flenmemi\u015f mesajlar\u0131) al\u0131r.<\/li>\nProcessedOn<\/code> alan\u0131n\u0131 g\u00fcncel tarihiyle doldurur ve Attempts<\/code> say\u0131s\u0131n\u0131 s\u0131f\u0131rlar. E\u011fer Kafka’ya g\u00f6nderim ba\u015far\u0131s\u0131z olursa, Attempts<\/code> say\u0131s\u0131n\u0131 art\u0131r\u0131r ve belirli bir tekrar deneme stratejisi (\u00f6rne\u011fin, \u00fcstel geri \u00e7ekilme) ile daha sonra tekrar denemeyi dener. Belirli bir deneme say\u0131s\u0131n\u0131 a\u015fan mesajlar i\u00e7in, manuel m\u00fcdahale gerektirebilecek bir “dead letter” (\u00f6l\u00fc mektup) durumuna d\u00fc\u015f\u00fcr\u00fcl\u00fcr veya \u00f6zel bir hata kuyru\u011funa y\u00f6nlendirilir.<\/li>\n<\/ol>\nIdempotent \u00d6deme \u0130\u015flemi Uygulamas\u0131:<\/h4>\n
OrderCreatedEvent<\/code> mesaj\u0131n\u0131 ald\u0131\u011f\u0131nda, \u00f6deme i\u015flemini ba\u015flat\u0131r. Ancak, ayn\u0131 orderId<\/code> i\u00e7in birden fazla \u00f6deme iste\u011fi gelirse (\u00f6rne\u011fin, Outbox r\u00f6lesi ayn\u0131 mesaj\u0131 birden \u00e7ok kez g\u00f6nderirse), \u00d6deme Servisi bunu alg\u0131lay\u0131p sadece ilkini i\u015flemek \u00fczere idempotent hale getirildi. Bu, \u00f6deme i\u015flemi s\u0131ras\u0131nda bir transactionId<\/code> veya orderId<\/code>‘yi kontrol ederek daha \u00f6nce i\u015flenip i\u015flenmedi\u011fini anlamas\u0131n\u0131 sa\u011flar.<\/p>\nSonu\u00e7lar\u0131 ve Kazan\u0131mlar:<\/h3>\n
\n
Geli\u015fmi\u015f Stratejiler: Daha Karma\u015f\u0131k Senaryolar \u0130\u00e7in \u0130pu\u00e7lar\u0131<\/h2>\n
Da\u011f\u0131t\u0131k \u0130zleme (Distributed Tracing): \u0130\u015flemlerin G\u00f6r\u00fcn\u00fcrl\u00fc\u011f\u00fcn\u00fc Art\u0131rma<\/h3>\n
\u0130\u015flem G\u00fcnl\u00fc\u011f\u00fc (Transaction Log) Tabanl\u0131 \u00c7\u00f6z\u00fcmler: CDC (Change Data Capture)<\/h3>\n
Event Sourcing (Olay Kaynaklama): Durum De\u011fi\u015fikliklerini Olay Ak\u0131\u015f\u0131 Olarak Kaydetme<\/h3>\n
S\u0131k\u00e7a Sorulan Sorular:<\/h2>\n
Veritaban\u0131 ve mesaj broker\u0131 aras\u0131nda atomikli\u011fi sa\u011flaman\u0131n en iyi yolu nedir?<\/h3>\n
Outbox deseni performans sorunlar\u0131na yol a\u00e7ar m\u0131?<\/h3>\n
\n
Saga deseni ne zaman kullan\u0131lmal\u0131d\u0131r?<\/h3>\n
Dead Letter Queue (DLQ) ne i\u015fe yarar?<\/h3>\n
Idempotent i\u015flemler neden bu kadar \u00f6nemlidir?<\/h3>\n
Sonu\u00e7: G\u00fcvenilir Da\u011f\u0131t\u0131k Sistemler \u0130n\u015fa Etmek<\/h2>\n