Mikroservis mimarileri, yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda esneklik, \u00f6l\u00e7eklenebilirlik ve ba\u011f\u0131ms\u0131zl\u0131k vaatleriyle h\u0131zla yayg\u0131nla\u015fm\u0131\u015ft\u0131r. Ancak bu mimarilerin getirdi\u011fi en b\u00fcy\u00fck zorluklardan biri, da\u011f\u0131t\u0131k sistemlerde veri tutarl\u0131l\u0131\u011f\u0131n\u0131 ve g\u00fcvenilir ileti\u015fimi sa\u011flamakt\u0131r. \u00d6zellikle bir servis kendi veritaban\u0131nda bir de\u011fi\u015fiklik yapt\u0131\u011f\u0131nda, bu de\u011fi\u015fikli\u011fi di\u011fer servislere g\u00fcvenilir bir \u015fekilde olay (event) olarak bildirmesi kritik \u00f6neme sahiptir. Bu makalede, bu zorlu\u011fun \u00fcstesinden gelmek i\u00e7in kullan\u0131lan g\u00fc\u00e7l\u00fc bir desen olan Transactional Outbox pattern’\u0131n\u0131 ve RabbitMQ ile entegrasyonunu detayl\u0131 bir \u015fekilde inceleyece\u011fiz.<\/p>\n
Mikroservisler aras\u0131 ileti\u015fimde olay odakl\u0131 mimariler, servislerin birbirleriyle do\u011frudan ba\u011f\u0131ml\u0131l\u0131k kurmadan asenkron bir \u015fekilde haberle\u015fmesini sa\u011flar. Bu yakla\u015f\u0131m, sistemin daha esnek ve hata toleransl\u0131 olmas\u0131na yard\u0131mc\u0131 olur.<\/p>\n
Olay odakl\u0131 ileti\u015fim, servislerin gev\u015fek bir \u015fekilde ba\u011flanmas\u0131n\u0131 (loosely coupled) sa\u011flar. Bir servis bir olay\u0131 yay\u0131nlad\u0131\u011f\u0131nda, di\u011fer servisler bu olay\u0131 dinleyebilir ve kendi i\u015f mant\u0131klar\u0131n\u0131 tetikleyebilir. Bu, servislerin ba\u011f\u0131ms\u0131z olarak geli\u015ftirilmesine, da\u011f\u0131t\u0131lmas\u0131na ve \u00f6l\u00e7eklenmesine olanak tan\u0131r. \u00d6rne\u011fin, bir “Sipari\u015f” servisi yeni bir sipari\u015f olu\u015fturdu\u011funda, “\u00d6deme” servisi \u00f6demeyi i\u015flemek i\u00e7in, “Envanter” servisi sto\u011fu g\u00fcncellemek i\u00e7in ve “Bildirim” servisi m\u00fc\u015fteriye e-posta g\u00f6ndermek i\u00e7in bu olay\u0131 dinleyebilir.<\/p>\n
Olay odakl\u0131 mimarilerde temel bir sorun ortaya \u00e7\u0131kar: Bir servis kendi veritaban\u0131nda bir de\u011fi\u015fiklik yapt\u0131\u011f\u0131nda ve ard\u0131ndan bu de\u011fi\u015fikli\u011fi bir mesaj kuyru\u011funa olay olarak g\u00f6nderdi\u011finde, bu iki i\u015flemin atomik (b\u00f6l\u00fcnmez) olmas\u0131 gerekir. Yani, ya her ikisi de ba\u015far\u0131l\u0131 olmal\u0131 ya da her ikisi de ba\u015far\u0131s\u0131z olmal\u0131d\u0131r. Aksi takdirde, veritaban\u0131nda bir de\u011fi\u015fiklik olurken olay yay\u0131nlanmazsa (veya tam tersi), sistemde veri tutars\u0131zl\u0131klar\u0131 meydana gelir.<\/p>\n
Geleneksel olarak, tek bir i\u015flem (transaction) i\u00e7inde veritaban\u0131 ve mesaj kuyru\u011fu i\u015flemlerini birle\u015ftirmek m\u00fcmk\u00fcn de\u011fildir. Veritaban\u0131 i\u015flemleri genellikle ACID \u00f6zelliklerini (Atomicity, Consistency, Isolation, Durability) desteklerken, mesaj kuyruklar\u0131 farkl\u0131 garanti seviyeleri sunar. Bu iki farkl\u0131 sistem aras\u0131nda atomik bir ba\u011f kurmak, da\u011f\u0131t\u0131k i\u015flemlerin karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 beraberinde getirir.<\/p>\n
Veri tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamak i\u00e7in kullan\u0131lan geleneksel y\u00f6ntemler, mikroservis mimarilerinde genellikle yetersiz kal\u0131r veya yeni sorunlar yarat\u0131r.<\/p>\n
\u0130ki A\u015famal\u0131 Taahh\u00fct (Two-Phase Commit – 2PC), birden fazla kat\u0131l\u0131mc\u0131 aras\u0131nda da\u011f\u0131t\u0131k bir i\u015flemi atomik olarak koordine etmek i\u00e7in tasarlanm\u0131\u015f bir protokold\u00fcr. Ancak 2PC, mikroservis ortamlar\u0131nda genellikle tercih edilmez. \u00c7\u00fcnk\u00fc:<\/p>\n
Mikroservislerde da\u011f\u0131t\u0131k i\u015flemler i\u00e7in daha yayg\u0131n bir yakla\u015f\u0131m, Saga desenidir. Saga, bir dizi yerel i\u015flemin s\u0131rayla y\u00fcr\u00fct\u00fcld\u00fc\u011f\u00fc ve her bir yerel i\u015flemin ba\u015far\u0131s\u0131z olmas\u0131 durumunda \u00f6nceki i\u015flemlerin telafi edici i\u015flemlerle geri al\u0131nd\u0131\u011f\u0131 bir desendir. Saga deseni, nihai tutarl\u0131l\u0131k (eventual consistency) modelini benimser, yani sistemin belirli bir s\u00fcre sonra tutarl\u0131 hale gelece\u011fi varsay\u0131l\u0131r. Ancak Saga’n\u0131n kendisi, yerel veritaban\u0131 de\u011fi\u015fikli\u011fi ile olay\u0131n yay\u0131nlanmas\u0131 aras\u0131ndaki atomikli\u011fi garanti etmez.<\/p>\n
Yukar\u0131daki zorluklar g\u00f6z \u00f6n\u00fcne al\u0131nd\u0131\u011f\u0131nda, mikroservislerin kendi veritaban\u0131 i\u015flemlerini tamamlad\u0131ktan sonra, bu olay\u0131 g\u00fcvenilir bir \u015fekilde mesaj kuyru\u011funa iletebilmesi i\u00e7in farkl\u0131 bir mekanizmaya ihtiya\u00e7 duyulur. \u0130\u015fte bu noktada Transactional Outbox deseni devreye girer.<\/p>\n
Transactional Outbox deseni, mikroservislerde veri tutarl\u0131l\u0131\u011f\u0131n\u0131 ve g\u00fcvenilir olay yay\u0131nlamay\u0131 sa\u011flamak i\u00e7in kullan\u0131lan bir yakla\u015f\u0131md\u0131r. Temel fikir, bir veritaban\u0131 i\u015flemi i\u00e7inde hem i\u015f verisini hem de yay\u0131nlanacak olaylar\u0131 ayn\u0131 anda kaydetmektir.<\/p>\n
Transactional Outbox deseninin temel prensibi \u015fudur: Bir servis kendi i\u015f verisinde bir de\u011fi\u015fiklik yapt\u0131\u011f\u0131nda (\u00f6rne\u011fin, bir sipari\u015f olu\u015fturdu\u011funda), bu de\u011fi\u015fikli\u011fi kendi veritaban\u0131na kaydederken, ayn\u0131 veritaban\u0131 i\u015flemi (transaction) i\u00e7inde, yay\u0131nlanacak olay\u0131n bir kopyas\u0131n\u0131 da \u00f6zel bir “Outbox” tablosuna kaydeder. Bu, i\u015f verisi de\u011fi\u015fikli\u011fi ve olay\u0131n kaydedilmesi i\u015flemlerinin atomik olmas\u0131n\u0131 sa\u011flar. E\u011fer veritaban\u0131 i\u015flemi ba\u015far\u0131l\u0131 olursa, hem i\u015f verisi hem de olay Outbox tablosunda kal\u0131c\u0131 hale gelir. E\u011fer i\u015flem ba\u015far\u0131s\u0131z olursa, her ikisi de geri al\u0131n\u0131r.<\/p>\n
Transactional Outbox desenini uygulamak i\u00e7in genellikle a\u015fa\u011f\u0131daki ad\u0131mlar izlenir:<\/p>\n
Bir servis, bir i\u015f i\u015flemi ger\u00e7ekle\u015ftirdi\u011finde (\u00f6rne\u011fin, yeni bir kullan\u0131c\u0131 kayd\u0131), bu i\u015flemi kendi veritaban\u0131nda ba\u015flat\u0131r. Bu i\u015flem s\u0131ras\u0131nda, i\u015f verisini g\u00fcnceller ve ayn\u0131 veritaban\u0131 i\u015flemi i\u00e7inde, yay\u0131nlamak istedi\u011fi olay\u0131 (\u00f6rne\u011fin, <\/code><\/p>\n Ayr\u0131 bir servis veya arka plan g\u00f6revi (genellikle \"Relay\" servisi olarak adland\u0131r\u0131l\u0131r), Relay servisi, Bu yakla\u015f\u0131m, i\u015f verisi de\u011fi\u015fikli\u011fi ve olay\u0131n kaydedilmesinin atomik olmas\u0131n\u0131 sa\u011flar. E\u011fer uygulama \u00e7\u00f6kerse veya mesaj kuyru\u011funa g\u00f6nderme i\u015flemi ba\u015far\u0131s\u0131z olursa, olay hala RabbitMQ, Transactional Outbox deseniyle m\u00fckemmel bir uyum i\u00e7indedir. Olaylar\u0131n g\u00fcvenilir bir \u015fekilde mesaj kuyru\u011funa iletilmesi ve t\u00fcketilmesi i\u00e7in \u00e7e\u015fitli mekanizmalar sunar.<\/p>\n Relay servisi, RabbitMQ, yay\u0131nc\u0131lar\u0131n mesajlar\u0131n\u0131n Broker taraf\u0131ndan al\u0131nd\u0131\u011f\u0131ndan ve i\u015flendi\u011finden emin olmalar\u0131n\u0131 sa\u011flayan \"Publisher Confirms\" \u00f6zelli\u011fine sahiptir. Relay servisi, bir mesaj\u0131 RabbitMQ'ya g\u00f6nderdi\u011finde, bu \u00f6zelli\u011fi kullanarak mesaj\u0131n ba\u015far\u0131l\u0131 bir \u015fekilde teslim edildi\u011fine dair bir onay bekleyebilir. E\u011fer onay gelmezse (\u00f6rne\u011fin, a\u011f hatas\u0131 veya RabbitMQ'nun \u00e7\u00f6kmesi), Relay servisi mesaj\u0131 tekrar g\u00f6ndermeyi deneyebilir.<\/p>\n Transactional Outbox deseni ve RabbitMQ entegrasyonunda, ayn\u0131 olay\u0131n birden fazla kez g\u00f6nderilme olas\u0131l\u0131\u011f\u0131 vard\u0131r (\u00f6rne\u011fin, Relay servisi bir olay\u0131 g\u00f6nderdikten sonra, onay almadan \u00f6nce \u00e7\u00f6kerse ve yeniden ba\u015flad\u0131\u011f\u0131nda ayn\u0131 olay\u0131 tekrar g\u00f6nderirse). Bu nedenle, olaylar\u0131 t\u00fcketen servislerin idempotent olmas\u0131, yani ayn\u0131 olay\u0131 birden fazla kez ald\u0131klar\u0131nda bile sistemde yan etki yaratmayacak \u015fekilde tasarlanmas\u0131 kritik \u00f6neme sahiptir. Her olaya benzersiz bir kimlik (UUID) eklemek ve t\u00fcketicilerin bu kimli\u011fi kullanarak olaylar\u0131 i\u015flem \u00f6ncesi kontrol etmesi yayg\u0131n bir yakla\u015f\u0131md\u0131r.<\/p>\n Transactional Outbox desenini uygularken baz\u0131 \u00f6nemli noktalara dikkat etmek gerekir.<\/p>\n \u0130\u015f mant\u0131\u011f\u0131n\u0131 i\u00e7eren servisler, veritaban\u0131 i\u015flemleri i\u00e7inde Outbox tablosuna olaylar\u0131 eklemekten sorumlu olacakt\u0131r. Bu i\u015flem, genellikle bir ORM (Object-Relational Mapper) veya Repository deseni kullan\u0131larak soyutlanabilir.<\/p>\n Relay servisi, Outbox tablosunu izleyen ve olaylar\u0131 RabbitMQ'ya g\u00f6nderen ba\u011f\u0131ms\u0131z bir bile\u015fendir.<\/p>\n Relay servisi, RabbitMQ'ya mesaj g\u00f6nderirken olu\u015fabilecek hatalar\u0131 y\u00f6netmelidir. Yeniden deneme mekanizmalar\u0131 (exponential backoff ile) ve ba\u015far\u0131s\u0131z mesajlar i\u00e7in bir \"Dead Letter Queue\" (DLQ) kullan\u0131m\u0131 \u00f6nemlidir. E\u011fer bir olay belirli say\u0131da denemeden sonra hala g\u00f6nderilemiyorsa, bu olay\u0131n DLQ'ya ta\u015f\u0131nmas\u0131 ve manuel m\u00fcdahale i\u00e7in i\u015faretlenmesi gerekebilir.<\/p>\n Transactional Outbox deseni, mikroservis mimarilerinde g\u00fcvenilir olay yay\u0131nlaman\u0131n temel ta\u015flar\u0131ndan biridir. \u0130\u015f verisi de\u011fi\u015fiklikleri ile olay yay\u0131nlama aras\u0131ndaki atomikli\u011fi sa\u011flayarak, da\u011f\u0131t\u0131k sistemlerde veri tutarl\u0131l\u0131\u011f\u0131 sorunlar\u0131na zarif bir \u00e7\u00f6z\u00fcm sunar. RabbitMQ gibi g\u00fc\u00e7l\u00fc bir mesaj arac\u0131s\u0131yla birle\u015fti\u011finde, bu desen servisler aras\u0131 ileti\u015fimin sa\u011flaml\u0131\u011f\u0131n\u0131 ve esnekli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r.<\/p>\n Bu makalede, Transactional Outbox deseninin temellerini, neden ihtiya\u00e7 duyuldu\u011funu ve RabbitMQ ile nas\u0131l entegre edilebilece\u011fini ele ald\u0131k. \"Transactional Outbox ile RabbitMQ (B\u00f6l\u00fcm 2)\" makalemizde, bu desenin daha ileri uygulamalar\u0131n\u0131, Change Data Capture (CDC) ile entegrasyonunu, hata y\u00f6netimi stratejilerini ve izleme (monitoring) konular\u0131n\u0131 daha derinlemesine inceleyece\u011fiz.<\/p>\n Do\u011frudan RabbitMQ'ya g\u00f6ndermek, veritaban\u0131 i\u015flemi ile mesaj g\u00f6nderme i\u015fleminin atomik olmamas\u0131n\u0131 sa\u011flar. E\u011fer veritaban\u0131 i\u015flemi ba\u015far\u0131l\u0131 olurken mesaj g\u00f6nderme ba\u015far\u0131s\u0131z olursa, sistemde veri tutars\u0131zl\u0131\u011f\u0131 olu\u015fur. Transactional Outbox, bu iki i\u015flemi tek bir veritaban\u0131 i\u015flemi i\u00e7inde birle\u015ftirerek atomikli\u011fi garanti eder.<\/p>\n Outbox tablosunun s\u00fcrekli b\u00fcy\u00fcmesi, performans sorunlar\u0131na yol a\u00e7abilir. Bu nedenle, olaylar ba\u015far\u0131yla yay\u0131nland\u0131ktan sonra Outbox tablosundan silinmeli veya ar\u015fivlenmelidir. Relay servisi, ba\u015far\u0131l\u0131 bir \u015fekilde g\u00f6nderilen olaylar\u0131 i\u015faretlemeli ve d\u00fczenli olarak temizlik i\u015flemleri yap\u0131lmal\u0131d\u0131r.<\/p>\n Hay\u0131r, olaylar kaybolmaz. Olaylar, i\u015f verisiyle birlikte veritaban\u0131ndaki Outbox tablosuna kal\u0131c\u0131 olarak kaydedildi\u011fi i\u00e7in, Relay servisi \u00e7\u00f6kse bile olaylar g\u00fcvende kal\u0131r. Relay servisi yeniden ba\u015flat\u0131ld\u0131\u011f\u0131nda, kald\u0131\u011f\u0131 yerden devam ederek hen\u00fcz yay\u0131nlanmam\u0131\u015f olaylar\u0131 i\u015fleyecektir.<\/p>\n Idempotency, ayn\u0131 i\u015flemin birden fazla kez uygulanmas\u0131n\u0131n ayn\u0131 sonucu vermesi veya ek yan etkiler yaratmamas\u0131 anlam\u0131na gelir. Transactional Outbox deseninde, Relay servisi veya RabbitMQ'nun kendisi nedeniyle ayn\u0131 olay\u0131n birden fazla kez g\u00f6nderilme olas\u0131l\u0131\u011f\u0131 her zaman vard\u0131r. T\u00fcketici servisler idempotent olarak tasarlanmazsa, ayn\u0131 olay\u0131 birden fazla kez i\u015fleyerek hatal\u0131 veri durumlar\u0131na veya istenmeyen yan etkilere neden olabilirler.<\/p>\n","protected":false},"excerpt":{"rendered":"Transactional Outbox ile RabbitMQ (B\u00f6l\u00fcm 1): Mikroservislerde G\u00fcvenilir Olay Yay\u0131nlama\nMikroservis mimarileri, yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda esnekl…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-37947","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nUserCreatedEvent<\/code>) \u00f6zel bir Outbox<\/code> tablosuna kaydeder.<\/p>\n\n\/\/ \u00d6rnek: C# ve Entity Framework Core\nusing (var transaction = _dbContext.Database.BeginTransaction())\n{\n \/\/ 1. \u0130\u015f verisini kaydet\n var user = new User { Name = \"John Doe\", Email = \"john.doe@example.com\" };\n _dbContext.Users.Add(user);\n _dbContext.SaveChanges();\n\n \/\/ 2. Olay\u0131 Outbox tablosuna kaydet\n var userCreatedEvent = new OutboxMessage\n {\n Id = Guid.NewGuid(),\n OccurredOn = DateTime.UtcNow,\n Type = \"UserCreatedEvent\",\n Payload = JsonConvert.SerializeObject(new { UserId = user.Id, UserName = user.Name })\n };\n _dbContext.OutboxMessages.Add(userCreatedEvent);\n _dbContext.SaveChanges();\n\n \/\/ 3. Veritaban\u0131 i\u015flemini tamamla\n transaction.Commit();\n}\n<\/pre>\nArka Plan \u0130\u015flemi (Relay)<\/h4>\n
Outbox<\/code> tablosunu s\u00fcrekli olarak izler. Bu izleme, belirli aral\u0131klarla tabloyu sorgulayarak (polling) veya veritaban\u0131n\u0131n Change Data Capture (CDC) \u00f6zelliklerini kullanarak yap\u0131labilir.<\/p>\nOlaylar\u0131n Mesaj Kuyru\u011funa G\u00f6nderilmesi<\/h4>\n
Outbox<\/code> tablosunda hen\u00fcz yay\u0131nlanmam\u0131\u015f olaylar\u0131 buldu\u011funda, bu olaylar\u0131 al\u0131r ve yap\u0131land\u0131r\u0131lm\u0131\u015f bir mesaj kuyru\u011funa (bu durumda RabbitMQ) g\u00f6nderir. Olay ba\u015far\u0131yla mesaj kuyru\u011funa g\u00f6nderildikten sonra, Relay servisi Outbox<\/code> tablosundaki ilgili olay\u0131n durumunu \"yay\u0131nland\u0131\" olarak g\u00fcnceller veya olay\u0131 siler.<\/p>\n\u0130\u015flem Atomikli\u011finin Sa\u011flanmas\u0131<\/h4>\n
Outbox<\/code> tablosunda durur ve Relay servisi taraf\u0131ndan tekrar i\u015flenebilir. Bu, olay\u0131n kaybolmamas\u0131n\u0131 garanti eder.<\/p>\nRabbitMQ ile Entegrasyon: Olaylar\u0131 G\u00fcvenle \u0130letme<\/h3>\n
RabbitMQ'nun Rol\u00fc<\/h4>\n
Outbox<\/code> tablosundan ald\u0131\u011f\u0131 olaylar\u0131 RabbitMQ'ya g\u00f6nderir. RabbitMQ, bu olaylar\u0131 ilgili Exchange'lere y\u00f6nlendirir ve oradan da kuyruklara da\u011f\u0131t\u0131r. Bu sayede, olay\u0131 dinleyen t\u00fcm servisler, olay mesaj\u0131n\u0131 alabilir.<\/p>\nMesaj Garanti Mekanizmalar\u0131 (Publisher Confirms)<\/h4>\n
Mesaj Tekrarlamas\u0131 ve Idempotency<\/h4>\n
Uygulama Ad\u0131mlar\u0131 ve Dikkat Edilmesi Gerekenler<\/h3>\n
Outbox Tablosu Tasar\u0131m\u0131<\/h4>\n
Outbox<\/code> tablosu, her olay\u0131n benzersiz bir kimli\u011fe sahip olmas\u0131n\u0131 ve gerekli t\u00fcm bilgileri i\u00e7ermesini sa\u011flamal\u0131d\u0131r. \u00d6rnek bir tablo yap\u0131s\u0131:<\/p>\n\n\n
\n \nKolon Ad\u0131<\/th>\n Veri Tipi<\/th>\n A\u00e7\u0131klama<\/th>\n<\/tr>\n<\/thead>\n \n Id<\/code><\/td>\nGUID<\/code><\/td>\nOlay\u0131n benzersiz kimli\u011fi<\/td>\n<\/tr>\n \n OccurredOn<\/code><\/td>\nDateTimeOffset<\/code><\/td>\nOlay\u0131n olu\u015ftu\u011fu zaman<\/td>\n<\/tr>\n \n Type<\/code><\/td>\nNVARCHAR(255)<\/code><\/td>\nOlay\u0131n tipi (\u00f6rn. \"UserCreatedEvent\")<\/td>\n<\/tr>\n \n Payload<\/code><\/td>\nNVARCHAR(MAX)<\/code><\/td>\nOlay\u0131n JSON format\u0131ndaki i\u00e7eri\u011fi<\/td>\n<\/tr>\n \n ProcessedDate<\/code><\/td>\nDateTimeOffset?<\/code><\/td>\nOlay\u0131n mesaj kuyru\u011funa g\u00f6nderildi\u011fi zaman (NULL ise g\u00f6nderilmedi)<\/td>\n<\/tr>\n \n Attempts<\/code><\/td>\nINT<\/code><\/td>\nG\u00f6nderme denemesi say\u0131s\u0131<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Olaylar\u0131 Yay\u0131nlama Servisi<\/h4>\n
Relay Servisi (Polling veya Change Data Capture)<\/h4>\n
\n
ProcessedDate<\/code> alan\u0131 NULL<\/code> olan kay\u0131tlar\u0131 sorgular ve bunlar\u0131 RabbitMQ'ya g\u00f6nderir. Ba\u015far\u0131l\u0131 g\u00f6nderimden sonra ProcessedDate<\/code> alan\u0131n\u0131 g\u00fcnceller.<\/li>\nHata Y\u00f6netimi ve Yeniden Denemeler<\/h4>\n
Sonu\u00e7 ve Gelecek B\u00f6l\u00fcm<\/h3>\n
SSS (S\u0131k Sorulan Sorular)<\/h3>\n
1. Neden do\u011frudan RabbitMQ'ya g\u00f6ndermiyoruz?<\/h4>\n
2. Outbox tablosu \u00e7ok b\u00fcy\u00fck olursa ne olur?<\/h4>\n
3. Relay servisi \u00e7\u00f6kerse olaylar kaybolur mu?<\/h4>\n
4. Idempotency neden \u00f6nemli?<\/h4>\n