Bir ekipte motivasyonun düştüğünü fark ettiğimizde ne yapıyoruz?

Ekip arkadaşlarımızla bire bir görüşmeler yapıyor, onları dinliyor, birlikte kahve molaları veriyor veya yeniden motive olmalarını sağlayacak konuşmalar yapıyoruz. Bunların hepsi önemli. Ancak bazen ne kadar çabalarsak çabalayalım, bir süre sonra aynı motivasyon kaybının tekrar yaşandığını görebiliyoruz.

Peki, bunun nedeni ne olabilir?

Bazen sorun, insanların ne yapacaklarını bilmemeleri değil, yaptıkları işe gerçekten inanmamaları olabilir.

Bir lider olarak yol gösterebilir, karşılaşılan engelleri kaldırabilir ve ekibimize destek olabiliriz. Ancak insanların yaptıkları işin neden önemli olduğunu anlamalarını sağlamak da en az bunlar kadar önemli.

Önce Lider İnanmalı

Ekibimizin bir hedefe inanmasını bekliyorsak önce kendimize şu soruyu sormalıyız: Biz o hedefe gerçekten inanıyor muyuz?

Yalnızca teslim tarihlerini takip ederek, görevleri dağıtarak veya hedefleri hatırlatarak insanların aynı heyecanı paylaşmasını bekleyebilir miyiz?

Bence liderin önce kendisinin yaptığı işe inanması gerekiyor. Üstelik bunu yalnızca konuşarak değil, davranışlarıyla da göstermesi önemli.

Gerektiğinde ekstra sorumluluk almak, zor zamanlarda ekibin yanında olmak ve yapılan işin neden değerli olduğunu anlatmak, insanların liderlerinden ilham alabilmesini sağlıyor.

Bir liderin söyledikleriyle yaptıkları birbirini desteklemediğinde, ekibin de anlatılan amaca inanmasını beklemek pek gerçekçi değil.

Golden Circle: Neden ile Başlamak

Simon Sinek, Start With Why kitabında Golden Circle adını verdiği bir modelden bahsediyor. Bu model üç temel sorudan oluşuyor:

• WHY: Bu işi neden yapıyoruz? Amacımız ne?
• HOW: Bu amacı nasıl hayata geçiriyoruz? Hangi değerler ve yaklaşımlarla hareket ediyoruz?
• WHAT: Sonuç olarak ne yapıyoruz, ne üretiyoruz?

Sinek’in yaklaşımında ilham veren liderler, iletişime ne yaptıklarını anlatarak değil, neden yaptıklarını açıklayarak başlıyor.

Bunu ekip yönetimi açısından düşündüğümüzde önemli bir fark ortaya çıkıyor.

Bir ekip arkadaşımıza hangi görevi tamamlaması gerektiğini ve ne zamana kadar bitirmesini beklediğimizi anlatabiliriz. Ancak bu görevin hangi probleme çözüm getirdiğini, neden önemli olduğunu ve ortaya çıkacak sonucun neyi değiştireceğini anlatmadığımızda, iş yalnızca tamamlanması gereken bir görev olarak kalabiliyor.

Oysa insanların yaptıkları işi önemsemeleri, o işi sahiplenmelerinin de başlangıcı olabilir.

Bir İşi Tamamlamak ile Sahiplenmek Aynı Şey mi?

Bir ekip arkadaşımızın kendisine verilen görevi tamamlaması elbette önemli. Ancak o işi gerçekten sahiplenmesi farklı bir şey.

Yaptığı işin neden önemli olduğunu bilen bir kişi, yalnızca kendisinden bekleneni yerine getirmekle yetinmeyebilir. Karşılaştığı sorunlara çözüm arar, gerektiğinde sorumluluk alır ve yaptığı işin üzerine bir şeyler koymaya çalışır.

Ancak burada yalnızca işin neden önemli olduğunu anlatmanın yeterli olduğunu düşünmüyorum.

Bir insan yaptığı işe inanabilir ama kararlarının sürekli sorgulandığı, hata yapmaktan çekindiği veya her adımda onay almak zorunda kaldığı bir ortamda ne kadar sorumluluk alabilir?

Lider olarak bazen ekip arkadaşlarımızın daha fazla inisiyatif almasını bekliyoruz. Fakat farkında olmadan onların hareket alanını da kendimiz sınırlandırabiliyoruz.

Bir görev verdiğimizde yalnızca beklediğimiz sonucu mu anlatıyoruz, yoksa o sonuca nasıl ulaşılması gerektiğini de baştan sona tarif ediyor muyuz?

Bence burada bir denge kurmamız gerekiyor. İnsanların yaptıkları işin neden önemli olduğunu anlamaları bir başlangıç. Ancak bu işi gerçekten sahiplenebilmeleri için onlara güvenmemiz ve kendi kararlarını verebilecekleri alanlar oluşturmamız gerekiyor.

Her Sorunun Çözümünü Biz mi Bulmalıyız?

Bir ekip arkadaşımız karşılaştığı sorunla bize geldiğinde, çözümü doğrudan söylemek çoğu zaman en kolay yol.

Elbette her durumda aynı yaklaşımı benimseyemeyiz. Projenin teslim tarihi, işin önceliği ve kişinin yetkinliği nasıl hareket edeceğimizi değiştirebilir.

Ancak şartlar uygunsa, önce kişinin kendi çözümünü geliştirmesine fırsat vermek gerektiğini düşünüyorum.

Çünkü bazen bizim aklımıza gelmeyen, hatta bizim tercih edeceğimiz yöntemden daha hızlı ve etkili çözümler ortaya çıkabiliyor.

Çözümü en baştan tarif ettiğimizde ise ekip arkadaşımız kendi yöntemini geliştirmek yerine bizim anlattığımız yolu takip edebiliyor.

İş tamamlanıyor. Peki, o kişinin farklı bir çözüm üretme fırsatını da ortadan kaldırmış olabilir miyiz?

Deneyimli olmak, her zaman en iyi çözümü bizim bildiğimiz anlamına gelmiyor.

Golden Circle’ın HOW kısmını liderlik açısından düşündüğümüzde, insanlara güvenmek, sorumluluk vermek ve kendi yöntemlerini geliştirmelerine alan açmak da bu yaklaşımın bir parçası olabilir.

Tabii ki bu, ekibi kendi haline bırakmak anlamına gelmiyor. Gerektiğinde destek olmak, riskleri takip etmek ve doğru zamanda müdahale etmek hâlâ bizim sorumluluğumuz.

Önemli olan, ne zaman yol göstermemiz ve ne zaman geri çekilmemiz gerektiğini bilmek.

Sorumluluk Vermek Kadar, Sorumluluk Almak da Önemli

Bir lider olarak ekip arkadaşlarımıza güvenebilir, onlara alan açabilir ve yaptıkları işin neden önemli olduğunu anlatabiliriz. Ancak bütün bunlar, karşı tarafın da aynı sorumluluğu almaya istekli olduğu anlamına gelmiyor.

Bence burada sorumluluk yalnızca lidere ait değil.

Bir kişinin yaptığı işin neden önemli olduğunu anlaması, o işi sahiplenmesi için iyi bir başlangıç. Ancak bunun yanında öğrenmeye, çözüm aramaya ve gerektiğinde kendi yöntemlerini sorgulamaya da istekli olması gerekiyor.

Diyelim ki ekip arkadaşımızın geliştirdiği bir çözüm beklediğimiz gibi çalışmadı.

Böyle bir durumda çözümü doğrudan devralmak yerine, neden işe yaramadığını birlikte değerlendirmek daha anlamlı geliyor. Hangi noktada sorun olduğunu anlatabilir, farklı bir yaklaşım önerebiliriz. Ancak sonrasında çözümü geliştirme sorumluluğunun yine o kişide kalması önemli.

Aynı durum, geliştirdiğimiz bir işte sonradan ortaya çıkan hatalar için de geçerli. Her sorunu liderin çözmesi yerine, işi geliştiren kişinin önce sorunu incelemesi ve çözüm üretmeye çalışması gerektiğini düşünüyorum.

Çünkü sorumluluk almak yalnızca bir görevi tamamlamak değil, o görevle ilgili karşılaşılan problemlerin de arkasında durabilmek.

Liderlik Yalnızca İşleri Yönetmek mi?

Bir ekibi yönetmekten bahsettiğimizde çoğu zaman aklımıza işlerin planlanması, görevlerin dağıtılması, teslim tarihlerinin takip edilmesi ve ortaya çıkan sorunların çözülmesi geliyor.

Ancak liderliğin yalnızca bunlardan ibaret olduğunu düşünmüyorum.

Bir lider olarak ekibimizdeki insanların nasıl geliştiğini de takip etmemiz gerekiyor. Hangi konularda güçlü olduklarını, nerelerde zorlandıklarını, zaman içerisinde ne kadar ilerlediklerini ve hangi alanlarda desteğe ihtiyaç duyduklarını anlamak da sorumluluklarımızın bir parçası.

Örneğin bir ekip arkadaşımızın birkaç ay önce tek başına çözmekte zorlandığı bir problemi bugün kendi başına çözebildiğini görmek, yalnızca o kişinin değil, ekibin de geliştiğini gösteriyor.

Bu gelişim her zaman kendiliğinden gerçekleşmiyor. Bazen daha fazla sorumluluk vermek, bazen geri bildirimde bulunmak, bazen de kişinin henüz hazır olmadığı bir konuda daha fazla destek sağlamak gerekiyor.

Ancak burada kişinin kendi isteğinin de önemli olduğunu düşünüyorum.

Öğrenmeye meraklı, sorumluluk almaya istekli ve kendini geliştirmek isteyen biriyle bu süreç çok daha hızlı ilerleyebiliyor. Karşılaştığı problemleri yalnızca aşılması gereken engeller olarak değil, yeni şeyler öğrenebileceği fırsatlar olarak da görebiliyor.

Diğer taraftan, gelişim için yalnızca liderin çaba göstermesi yeterli olmayabiliyor. Ne kadar destek verirsek verelim, kişinin de bu sürecin bir parçası olmayı istemesi gerekiyor.

Bu nedenle liderin görevi yalnızca gelişim fırsatları sunmak değil, kişinin motivasyonunu, performansını ve ihtiyaçlarını da anlamak. Herkes aynı hızda öğrenmeyebilir veya aynı dönemde aynı motivasyona sahip olmayabilir. Önemli olan, bu farklılıkları görerek doğru zamanda doğru desteği sağlayabilmek.

Belki de lider olarak yapabileceğimiz en önemli şeylerden biri, insanlara gelişebilecekleri bir ortam sunmak ve bu gelişimin sorumluluğunu onlarla paylaşmak.

Peki, Biz Nasıl Bir Ekip Oluşturmak İstiyoruz?

Her sorunda liderinin karar vermesini bekleyen bir ekip mi, yoksa karşılaştığı sorunları sahiplenip çözüm üretebilen bir ekip mi?

Aslında çoğumuz ikinci seçeneği tercih ederiz. Ancak günlük hayatta aldığımız kararlarla her zaman bunu destekliyor muyuz?

Bir yandan ekip arkadaşlarımızın daha fazla sorumluluk almasını isterken diğer yandan her çözümü kendimiz belirliyorsak, onlara ne kadar alan bırakıyoruz?

Golden Circle’a yeniden döndüğümüzde, WHY ile başlamak insanların yaptıkları işin amacını anlamalarına yardımcı oluyor. Ancak bu amacı günlük hayata taşıyabilmek için güven, sorumluluk ve gelişim fırsatlarıyla desteklememiz gerekiyor.

Bir lider olarak yalnızca bugün hangi işleri tamamladığımıza değil, ekibimizin zaman içerisinde nasıl geliştiğine de bakmalıyız.

Çünkü bir ekibin başarısı yalnızca ortaya çıkardığı sonuçlarla değil, o sonuçlara ulaşırken insanların kazandığı yetkinliklerle de ilgili.

Belki de lider olarak kendimize daha sık sormamız gereken soru şu:

Ekibimizin bize daha fazla ihtiyaç duymasını mı sağlıyoruz, yoksa zamanla bize daha az ihtiyaç duyacak kadar gelişmelerine mi yardımcı oluyoruz?

Bir Liderin En Önemli Sorusu: Neden? was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sabah mutlu bir şekilde uyandınız; içinizde tatlı bir enerji, “Bugün işler yolunda gidecek” hissi vardı. İşe geldiğinizde ne yapacağınız belliydi, motiveydiniz. Ofise yayılmış o mis gibi taze kahve kokusu dayanılmaz gelince hemen makinenin başına yöneldiniz.

Tam o sırada, uzun zamandır aynı şirkette çalıştığınız takım arkadaşınız da oradaydı. Kahvesini alıyordu ama yüzünde alışılmadık bir yorgunluk, hafif bir dert hali vardı.

Biraz sohbet edince içini döktü: Yöneticisiyle konuşmuş, beklediği terfiyi alamamış. Üstüne bir de başka şirketlerden aldığı iş tekliflerini düşündüğünü söyledi.

Masanıza geçtiğinizde onun adına gerçekten üzüldünüz. İçinizde ufak bir sıkıntı belirdi. Ama bir yandan da şaşırdınız: Çünkü sizin yöneticinizle böyle bir sorununuz yoktu, üstelik güne gayet keyifli başlamıştınız.

Peki nasıl oldu da arkadaşınızın yaşadığı hayal kırıklığının tadı sizin ruh halinize de karıştı?

Aslında hepimizin yaşadığı çok tanıdık bir durum bu. Sabah trafikte yaşadığınız minicik bir gerginliğin gün boyu peşinizi bırakmaması ya da takım liderinizin yaklaşan deadline için yaşadığı paniğin size de bulaşması gibi…

Aslında yaşadığınız şeyin bir adı var: İkinci el stres. Kulağa bir hastalık gibi gelebilir ama değil; bu bir psikolojik bozukluk ya da tıbbi bir teşhis değil. Daha çok duyguların insandan insana nasıl geçtiğini anlatan nörolojik bir durum. Yani birinin yaşadığı kaygı, farkında bile olmadan sizde de karşılık buluyor.

İkincil Stresin Etkileri: Neden Bu Kadar Hızlı Bulaşıyor?

İkincil stres, çoğu zaman farkında olmadan maruz kaldığımız ve düşündüğümüzden çok daha geniş bir alana yayılan bir etki yaratıyor. Bunun temel nedeni, beynimizin sosyal sinyalleri işleme biçiminde yatıyor. İnsan beyni, özellikle de ayna nöron sistemi, karşısındaki kişinin duygusal durumunu “okumakla” kalmaz, onu otomatik olarak taklit etmeye eğilimlidir. Bu biyolojik eğilim, sosyal uyum için oldukça faydalıdır; ancak yoğun stres yüklü ortamlarda bizi savunmasız hâle getirir.

Örneğin, ekip arkadaşınız baskı altındaysa, sürekli kötü haber veriliyorsa, müşteri bekliyorsa veya yöneticisinden olumsuz geri bildirim almışsa, bu gerginlik yalnızca ona ait kalmaz. Yüzündeki mikro ifadelerden, ses tonundaki sertlikten, hızlı nefes alışından veya mesajlarında kullandığı kelime seçimlerinden bile stres size taşınabilir. Bazen gün sonunda “Bugün neden bu kadar yorgunum?” diye sorarken, bunun kaynağı doğrudan yaşadığınız bir durum değil; çevrenizden üzerinize geçen stres olabilir.

İkincil stresin etkileri yalnızca duygu durumumuzu değil, karar alma kapasitemizi, üretkenliğimizi, ilişkilerimizi ve hatta fizyolojik tepkilerimizi de değiştirir. Sanki zihinsel bir ekranın parlaklığı azalır: Daha çabuk sinirlenir, daha zor odaklanır, daha az empati gösterir ve küçük sorunları büyükmüş gibi algılamaya başlarız.

En tehlikeli yanı ise normalleşmesi. Zamanla bu duygu hâli bir arka plan sesi gibi sürekli çalışır ve siz fark etmiyorsunuzdur bile. Bu nedenle ikincil stresi fark etmek, isimlendirmek ve yönetmek; yalnızca bireysel iyilik hâli için değil, ekip dinamikleri ve iş kalitesi için de kritik bir beceri hâline gelir.

Çevresel Faktörlerin Etkisi

İkinci el stresi tetikleyen bir diğer unsur da fiziksel çevremiz. Ortada sizi strese sokacak gerçek bir durum olmasa bile, kaotik, kalabalık ya da sürekli gürültülü bir ortamda bulunmak bile bu stresin size bulaşmasına yetiyor.

Hatta işin ilginci, birinin stresini hissetmek için o kişiyi görmeniz ya da duymanız bile gerekmiyor; kokusundan¹ bile size geçebiliyor. Araştırmalar, stres altındaki insanların vücutlarının, aynı ortamda bulunan kişiler tarafından fark edilmeden algılanabilen özel bir hormon salgıladığını gösteriyor. Yani yaşadığınız olumsuzluk ve gerginlik, farkında olmadan tüm ortama yayılıyor.

Yüksek etkileşimin olduğu yaşantımızda diğer insanlara çok fazla maruz kalabiliyoruz. Bu da olumsuz duyguların ve stresin daha da bulaşıcı olmasına sebep oluyor. Sosyal medyada gördüğünüz bir haber gün içinde size ve dolaylı olarak çevrenizdeki kişilere yansıyor. Sürekli bildirim alan, haber tüketen ve dijital yorulma yaşayan bir dünyada duygusal mesafe korumak zorlaştı.

İkincil strese nasıl bağışıklık kazanabiliriz?

Araştırmalar, strese yönelik daha olumlu bir zihinsel çerçeve benimsendiğinde ve stresle sürekli çatışma hâlinin bırakıldığında, stresin olumsuz etkilerinin %23 oranında azaldığını² ortaya koyuyor. Bu bakış açısını geliştirmek başlangıçta kolay olmayabilir; ancak elde edilen sonuçlar, bu yaklaşımın denenmeye değer ve etkili bir yöntem olduğunu açıkça gösteriyor.

İkincil strese tamamen “duvar örmek” mümkün olmasa da, ona karşı güçlü bir duygusal bağışıklık sistemi geliştirmek mümkün. Bunun ilk adımı, başkalarının duygularını kendi duygularınız gibi içselleştirdiğiniz anları fark edebilmek.

Birinin gerginliği size geçtiğinde bedeninizin verdiği sinyalleri — omuzlarda kasılma, nefesin hızlanması, zihnin daralması — yakalamak, bu döngüyü kırmanın en etkili yollarından biridir.

Sonraki adım ise zihinsel bir mesafe yaratmak: “Bu duygu bana ait değil.” diyebilmek. Bu farkındalık, başkalarının stresine otomatik olarak kapılma eğiliminizi belirgin şekilde azaltır.

Ayrıca gün içinde kısa odaklanma molaları vermek, nefes egzersizleriyle sinir sistemini düzenlemek ve iş ortamındaki duygusal yoğunlukları bilinçli olarak sınırlamak; ikincil strese karşı gerçek bir kalkan oluşturur.

Başkalarının duygularını anlamaya devam ederken, kendinizi duygusal olarak sağlam bir zeminde tutabilmek ise uzun vadede en etkili bağışıklık yöntemidir.

Bu noktada tüm bu kavramların benim hayatımdaki karşılığını çalışma düzenim değiştiğinde çok daha net anladım.

Ben de çalışma hayatımın yaklaşık yedi yılını tam zamanlı ofiste geçirdim. Sonradan fark ettim ki, o dönemde sık sık hissettiğim ama adını bir türlü koyamadığım şey aslında ikinci el stresti. Ofiste fark etmeden yüklendiğim stresin, evden çalışmaya geçtiğimde bir anda azalması aslında bu kavramı daha iyi anlamamı sağladı.

Son üç yıldır evden çalışırken fark ettiğim en belirgin değişim, yaşadığım olaylara çok daha sakin tepki vermem oldu. Çünkü artık yöneticimin gergin bir sunumunun ortasında kalmıyor, yan masamdaki arkadaşımın aile sorunlarının yarattığı gerginlikten etkilenmiyor, kimsenin stresini istemeden üzerime almıyordum.

Elbette uzaktan çalışmanın herkes için farklı sonuçları var; kimi için avantaj, kimi için dezavantaj. Ancak en azından benim için bu konu özelinde olumlu tarafı çok daha baskın oldu.

Bu yazıda bahsettiğim bilgiler ilginizi çekiyorsa, Harvard Business Review’ın Emotional Intelligence Series kitaplarını incelemenizi öneririm. Özellikle ikincil stres konusunda daha derin bir perspektif arıyorsanız, Positivity and Growth kitabındaki ‘Make Yourself Immune to Secondhand Stress and Negativity’ bölümü merak ettiğiniz konuları kapsamlı bir şekilde ele alıyor.

Sonuç olarak, başkalarının stresinin bize bulaşması doğal; ancak bunu ne kadar taşıyacağımız bizim elimizde. Kendiniz için bir alan açmanız, sadece sizin için değil, çevrenizdekiler için de en değerli iyilik olabilir.

🧩 Mini Öneriler: İkincil Strese Karşı Günlük Kalkanlar

1. Duyguyu Sahiplik Testi Yap

“Bu duygu bana mı ait, yoksa başkasından mı geliyor?”
Günde birkaç kez bu soruyu kendine hatırlatmak, duygusal sınır çizmeye yardımcı olur.

2. Kısa molalar ver

2–3 dakikalık kısa yürüyüşler, pencereden dışarı bakmak, derin nefes almak…
Bu küçük aralar sinir sistemini sıfırlar.

3. Tetikleyicileri Tanı

Kimlerin veya hangi ortamların sende gerginlik yarattığını fark et.
Farkında olmak, etkilenmeyi otomatik olarak azaltır.

4. Dijital Gürültüyü Azalt

Sosyal medya, Slack, Whatsapp grupları…
Yazılan her mesaja hemen dönmek zorunda değilsin öncelikleri yönetebilirsin. Gün içinde bilgi akışını sınırlamak ikincil stresi ciddi oranda azaltır.

5. Kontrollü Empati Kullan

Empati kur, ancak duyguyu üstüne alma.
“Anlıyorum ama taşımak zorunda değilim” prensibi burada çok işe yarar.

📌 Kaynakça

¹Dalton, P., Mauté, C., Jaén, C., & Wilson, T. (2013). Chemosignals of Stress Influence Social Judgments. PLOS ONE, 8(10).
https://doi.org/10.1371/journal.pone.0077144

² Crum, A. J., Salovey, P., & Achor, S. (2013). Rethinking Stress: The Role of Mindsets in Determining the Stress Response. Journal of Personality and Social Psychology, 104(4), 716–733.
https://doi.org/10.1037/a0031201

İkinci El Stres: Başkalarının Duyguları Bize Neden Bu Kadar Hızla Bulaşıyor? was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

İş Hayatında Heyecan Kaybı

En tehlikeli kayıp, bir çalışanın işten ayrılması değildir.
Hâlâ masasında otururken içindeki heyecanın sessizce sönmesidir.

Okuldan mezun olup ilk işimize başladığımızda iş hayatının dinamiklerini çoğu zaman tam olarak öngöremeyiz. Üniversitede projelerdeki en büyük kısıt genellikle zamandır. Oysa iş dünyasında sorumluluklarımız yalnızca kendi görev tanımımızla sınırlı değildir; ekip dinamikleri, organizasyonel hedefler ve süreç beklentileriyle iç içedir.

Başlangıçta hevesle katkı sunmak isteyen bir çalışan, fikirleri sürekli geri çevrildiğinde yavaş yavaş savunmaya geçer. Artık yenilik üretmeye değil, hata yapmamaya odaklanır. Görünmez olmak, risk almaktan daha güvenli hissettirmeye başlar.

Beynimizdeki keşfetme (seeking) sistemi merakı, öğrenme arzusunu ve üretme motivasyonunu tetikler. Ancak sürekli baskı ve yoğun eleştiri, korku sistemini aktive eder. Korku devreye girdiğinde çalışan yeni fikirler denemekten çekinir; risk almak tehdit gibi algılanır. Merak sessizleşir, motivasyon azalır.

Bu noktada kurumlar potansiyel dolu bir enerjiyi kaybeder.
Çalışanlar ise iş saatlerini anlam üretmeden geçirmeye başlar.

Kaybedilen yalnızca performans değildir. Kaybedilen; enerji, motivasyon ve yapılan işten alınan tatmindir.

Keşfetme vs. Korku: Beynimizdeki İki Güç ve Farelerden İnsanlara Panksepp’in Öğrettiği Dersler

Nörobilimci Jaak Panksepp², fareler üzerinde yaptığı çalışmalarla beynimizdeki temel duygusal sistemleri ortaya koymuştur. Bu sistemlerden biri keşfetme (seeking), diğeri ise korkudur.

Laboratuvarda iki genç fare bir araya getirildiğinde neredeyse her zaman oyun başlar: kovalamaca, güreş, karşılıklı davetler… Araştırmalara göre bu oyun sırasında fareler 50 kHz frekansında cıvıldamalar çıkarır. Bu sesler onların “gülmesi” olarak yorumlanır. Yani oyun anında ölçülebilir bir heyecan ve pozitif uyarılma vardır.

Oyun aslında bir deneme-yanılma alanıdır. Fareler burada güçlerini, çevikliklerini ve sosyal sınırlarını keşfederler. Benzer şekilde bebekler de dünyayı oyun yoluyla öğrenir; fiziksel ve sosyal becerilerini geliştirir. Çoğu memelide oyun dürtüsü vardır. Oyun, potansiyeli keşfetmenin doğal yoludur.

Ancak deneyin en çarpıcı kısmı bundan sonradır.

Araştırmacılar oyun alanına küçük bir kedi tüyü koyarlar. Gerçek bir tehdit yoktur; yalnızca koku vardır. Fakat bu koku farelerin içgüdüsel korku sistemini aktive etmeye yeter.

Sonuç çarpıcıdır:

• Deney öncesinde beş dakikalık bir seansta ortalama 50 oyun daveti yapılırken,
• Kedi tüyü konduktan sonra bu sayı sıfıra düşer.
• Kontrol grubunda ise oyun davranışı aynı şekilde devam eder.

Daha da dikkat çekici olan, tüy kaldırıldıktan sonra bile oyunun hemen geri dönmemesidir. Üç gün sonra fareler tekrar oynamaya başlar; ancak hiçbir zaman eski seviyeye tam olarak ulaşamazlar.

Korku devreye girdiğinde keşif ve oyun sistemi baskılanır ve güven geri gelse bile toparlanmak zaman alır.

İnsan beyni de benzer bir mekanizmayla çalışır. Korku, merak ve yaratıcılığı anında durdurabilir.

Gaz ve Fren: İş Hayatında Duygusal Denge

Beynimizdeki keşfetme ve korku sistemini bir arabanın gaz ve fren pedalları gibi düşünebiliriz. Bu analoji Alive at Work¹ kitabında da etkileyici bir şekilde anlatılır.

• Gaz pedalı bizi ileri taşır: yeni fikirler, denemeler, yenilik.
• Fren pedalı bizi korur: risk yönetimi, dikkat, kontrol.

Her ikisi de gereklidir.

Bir yazılım ekibini düşünelim. Eğer ekip sürekli baskı altındaysa, hatalardan dolayı eleştiriliyor ve risk almak cezalandırılıyorsa frenler sürekli devrededir. Kimse yeni teknolojileri denemek istemez. Kimse radikal bir fikir önermez. Herkes güvenli alanında kalmayı tercih eder.

Gaz pedalı çalışsa bile fren basılıyken araç ilerlemez.

Tersine, güvenli ve destekleyici bir ortamda keşfetme sistemi aktive olur. İnsanlar fikir paylaşır, yeni çözümler dener, öğrenir. Ancak fren tamamen kaldırılırsa bu da kontrolsüz risklere yol açabilir.

Yüksek performans; korkunun yokluğu değil, keşfetme ile korunma arasındaki sağlıklı dengedir.

Liderliğin Asıl Rolü

Bu noktada liderliğin rolü kritik hale gelir.

Etkili bir lider, ekibinin korku sistemini gereksiz yere tetiklemez. Psikolojik güven inşa eder. İnsanların hata yapma korkusu olmadan fikir paylaşabileceği bir alan yaratır.

Merakı ve heyecanı harekete geçiren liderler ekiplerinde şunları gözlemler:

• Daha fazla yaratıcı çözüm
• Daha hızlı problem çözme
• Daha yüksek iç motivasyon
• Daha sürdürülebilir performans

Çünkü insanlar korktuklarında korunurlar.
Heyecanlandıklarında ise üretirler.

İş hayatında gerçek kayıp, bir çalışanın ayrılması değildir.
Gerçek kayıp, onun hâlâ oradayken içindeki keşfetme isteğinin sönmesidir.

Sorumluluk Verdikçe Artan Performans

Liderlik yolculuğumda fark ettiğim en net şeylerden biri şu oldu:

Kontrol ettikçe değil, sorumluluk verdikçe ekip büyüyor.

Başta refleksim, kritik işleri kendimden geçirmek, son kararı ben vermek ve riskli gördüğüm noktaları sıkı takip etmekti. Bunun kaliteyi koruyacağını düşünüyordum.

Ama bir noktada bilinçli bir deneme yaptım.

Bazı kararları ekip arkadaşlarıma bıraktım.
Bazı projelerde yönü ben çizmek yerine çerçeveyi çizip alan açtım.
Sadece “nasıl yapılacağına” değil, “neden yaptığımıza” odaklandım.

Ve şunu gözlemledim:

Sorumluluk alan insanlar daha fazla sahipleniyor.
Sahiplenen insanlar daha yaratıcı düşünüyor.
Yaratıcı düşünen insanlar daha yüksek performans gösteriyor.

En ilginci ise şuydu:
Hata oranı artmadı. Aksine, insanlar kendi kararlarının sonuçlarını gördükçe daha dikkatli ve bilinçli hareket etmeye başladı.

O an şunu anladım:

Mikro yönetim fren sistemini güçlendiriyor.
Yetki ve sorumluluk ise keşfetme sistemini aktive ediyor.

İnsanlara alan açtığınızda sadece işi devretmiş olmuyorsunuz; aynı zamanda onların potansiyeline güvendiğinizi de göstermiş oluyorsunuz. Bu güven, performansın en görünmez ama en güçlü tetikleyicilerinden biri.

Sonuç: Bir Ekibi Hızlandıran Şey Baskı Değil, Meraktır

Bugün şunu çok daha net görüyorum: insanlar kapasite eksikliğinden değil, güven eksikliğinden yavaşlıyor.

Korku düzen sağlar ama potansiyel üretmez.
Heyecan ise risk içerir ama değer üretir.

Bir liderin asıl görevi her şeyi kontrol etmek değil; insanların içindeki keşfetme sistemini canlı tutmaktır.

Ve liderlik aslında şudur:
Ekibin gaz pedalına basmasını sağlamak değil; frene basma ihtiyacı hissetmeden çalışabilecekleri bir ortam yaratmaktır.

Çünkü bir ekipte performans düşmeden önce merak azalır.
Ve liderlik, bu merakı canlı tutabilme sanatıdır.

📌 Kaynakça

¹ Cable, Daniel M. Alive at Work: The Neuroscience of Helping Your People Love What They Do. Wiley, 2019. https://www.oreilly.com/library/view/alive-at-work/9781633697676/

²Wright, Jason & Panksepp, Jaak. (2012). An Evolutionary Framework to Understand Foraging, Wanting, and Desire: The Neuropsychology of the SEEKING System. Neuropsychoanalysis. 14. 5–39. 10.1080/15294145.2012.10773683.

Korku Beyni Savunmaya Alır, Heyecan Üretime: İş Hayatında Duyguların Performansa Etkisi was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yazılım kariyerimin büyük bölümünde gelişmenin yolunun daha iyi bir mühendis olmaktan geçtiğini düşündüm.

Daha temiz kod yazmak, daha karmaşık problemleri çözmek, sistemleri daha iyi tasarlamak, yeni teknolojiler öğrenmek…

Junior’dan Mid’e, Mid’den Senior’a ilerlerken bunların hepsi beni ileri taşıdı. Fakat bir noktadan sonra bir şeylerin değiştiğini fark etmeye başladım.

Daha iyi kod yazmak artık tek başına yeterli değildi.

Çünkü karşıma çıkan problemler artık yalnızca kodla çözülebilen problemler değildi. Bir projenin neden ilerlemediğini anlamak, takım arkadaşımın önündeki engeli kaldırmak, belirsiz bir konuda yön göstermek veya henüz ortaya çıkmamış bir riski fark etmek de işin bir parçasıydı.

Asıl değişen ise kendime sorduğum soruydu.

“Bu problemi nasıl çözerim?”

yerine zamanla:

“Bu problemi takım olarak daha iyi çözmemizi nasıl sağlayabilirim?”

diye düşünmeye başladım.

Kariyerimizin bir noktasından sonra mesele yalnızca kendi çıktımızı artırmak değil, çevremizdeki insanların etkisini de artırabilmek.

Bunun için benim de çok sevdiğim bir kavram var: Team Multiplier.

Bir team multiplier yalnızca kendi üretkenliğine odaklanmıyor. Takım arkadaşlarının önündeki engelleri kaldırıyor, daha iyi kararlar almalarına yardımcı oluyor ve takımın bir bütün olarak daha iyi sonuç üretmesine katkı sağlıyor.

Kendi deneyimlerime baktığımda bu konuda beş özellik benim için öne çıkıyor:

Credibility. Reliability. Proactivity. Pragmatism. Resourcefulness.

Bunları yalnızca Senior veya Lead Developer’ların sahip olması gereken özellikler olarak görmüyorum. Kariyerimizin hangi noktasında olursak olalım, çevremizde yarattığımız etkiyi artırmak için geliştirebileceğimiz özellikler olduğunu düşünüyorum.

1. Credibility — Güven Kazanmak

Credibility’nin yalnızca teknik olarak doğru kararlar vermekle oluştuğunu düşünmüyorum. Benim için güven, zamanla takım arkadaşlarımla kurduğum ilişkilerde ve özellikle zor anlarda verdiğim tepkilerde oluşmaya başladı.

Bunu en çok birkaç durumda fark ettim.

Takım arkadaşlarım bana bir konuda fikir danıştığında kendi fikrimi paylaşsam da son kararı onlara bırakmaya çalışıyorum. Benim önerdiğim yolu seçmelerini beklemek yerine, kendi kararlarını almaları ve uygulamaları için alan tanımanın daha değerli olduğunu gördüm.

Çünkü birinin sana fikrini sorması, kararı senin vermeni istediği anlamına gelmiyor. Bazen sadece düşüncesini birlikte değerlendirebileceği birine ihtiyaç duyuyor.

Bir diğer nokta ise bir problem yaşandığında nasıl tepki verdiğimiz.

Bir hata yapıldığında:

“Bunu neden böyle yaptın?”

demek yerine:

“Ortada bir problem var, bunu beraber çözebiliriz.”

diyebilmenin çok şeyi değiştirdiğini gördüm.

Yazılım geliştirirken hata yapmak kaçınılmaz. Böyle anlarda hatayı yapan kişiyi aramak yerine çözümün bir parçası olmaya çalışmak, insanların bir problem yaşadıklarında bunu saklamak yerine daha rahat paylaşmalarını sağlıyor.

Stresli anlarda verdiğimiz tepkinin de düşündüğümüzden daha önemli olduğunu düşünüyorum. Production’da bir problem olabilir, proje yetişmiyor olabilir veya yanlış bir karar verilmiş olabilir. Böyle zamanlarda sakin kalabilmek ve insanlara karşı aynı şekilde kibar davranmaya devam etmek zaman içerisinde güven oluşturuyor.

Tanya Reilly’nin The Staff Engineer’s Path kitabını okurken de benzer bir nokta dikkatimi çekmişti. Reilly, credibility’nin yalnızca teknik yetkinlikle oluşmadığından; insanlarla kurduğumuz iletişimin ve zor durumlarda nasıl davrandığımızın da güven üzerinde önemli bir etkisi olduğundan bahsediyor.

Bu kısmı okuduğumda kendi deneyimlerimle oldukça örtüştüğünü düşündüm. Her şey yolundayken sakin ve destekleyici olmak kolay. İnsanların bize gerçekten güvenmesini sağlayan şeylerden biri, işler ters gittiğinde nasıl davranacağımızı bilmeleri.

Asıl güven, işler yolunda gitmediğinde insanların bizim nasıl davranacağımızı bilmesiyle oluşuyor.

Credibility’yi kendim için şöyle özetliyorum:

“Onun fikrine ve yaklaşımına güveniyorum.”

2. Reliability — Sen Orada Olmadığında da Güvenebilmek

Credibility ve reliability ilk bakışta birbirine oldukça yakın geliyor. Ben aralarındaki farkı şu iki cümleyle ayırmayı seviyorum:

Credibility: “Onun fikrine ve yaklaşımına güveniyorum.”

Reliability: “Ben orada olmasam bile ona güveniyorum.”

Reliability denildiğinde ilk akla gelen verilen işi zamanında tamamlamak veya verilen sözleri tutmak olabilir. Bunlar tabii ki önemli. Ama benim için zamanla biraz daha farklı bir anlam kazandı.

Bir sorunun çözüleceği veya yeni bir feature’ın konuşulacağı toplantıyı düşünelim.

Katılımcıları gördüğümde:

“X zaten bu toplantıda olacak. Konuyu çok iyi anlayacaktır, benim katılmama gerek yok.”

diyebiliyorsam, benim için reliability’nin en güzel örneklerinden biri bu.

Birine gerçekten güvenmek, yalnızca ona bir task verip tamamlamasını beklemek değil. Sen orada olmadığında da konuyu sahipleneceğini, gerekli soruları soracağını ve gerektiğinde aksiyon alacağını bilmek.

Bu güven her yerde bulunma ihtiyacımızı da azaltıyor. Her toplantıya katılmak, her teknik kararın içinde olmak veya her problemi kendimiz takip etmek zorunda değiliz. Takımdaki insanlara gerçekten güvenebildiğimizde sorumluluğu da paylaşabiliyoruz.

Reliability’nin değerini işler ters gittiğinde de daha net görüyorum.

Bir hata veya production problemi yaşandığında, o alanı çok iyi bilmese bile bir takım arkadaşının:

“Bu benim yaptığım bir şey değil.”

deyip kenara çekilmek yerine takıma destek olması benim için çok değerli.

Her zaman çözümü bilmek zorunda değiliz. Bazen doğru kişiye ulaşmak, araştırmaya yardımcı olmak veya sadece problemin çözümünde takımın yanında olmak bile yeterli.

Bir de çok basit görünen ama benim önem verdiğim bir davranış var: takip edilmeyi beklememek.

Bir işi sahiplendiğinde insanların sürekli “Ne oldu?”, “Bir gelişme var mı?” veya “Konuşabildin mi?” diye sormasına gerek kalmadan gelişmeleri paylaşmak. Bir engel veya risk varsa bunu son ana bırakmadan söylemek.

Sonuçta reliability benim için şu noktaya geliyor:

Sen orada olmasan bile insanların konunun güvende olduğunu bilmesi.

3. Proactivity — Verilen Görevin Ötesini Görebilmek

Proaktif olmak bazen yanlış anlaşılıyor.

Her işe gönüllü olmak, sürekli yeni sorumluluk almak veya karşılaşılan her problemi kendi başına çözmeye çalışmak proaktif olmak gibi görülebiliyor.

Ben ise biraz farklı düşünüyorum.

Proaktif olmak, daha fazla iş yapmak değil; verilen görevin ötesine bakıp büyük resmi görebilmek.

Bir feature geliştirirken sana verilen task’ı tamamlamış olabilirsin. Ama yaptığın değişikliğin başka bir sistemi nasıl etkileyeceğini, başka bir takımın aksiyon alması gerekip gerekmediğini veya bugün aldığımız bir kararın birkaç hafta sonra nasıl bir probleme dönüşebileceğini de düşünmek gerekiyor.

Aynı şekilde “Burası beni ilgilendirmiyor.” demeden önce bir adım daha düşünmek gerektiğine inanıyorum.

Takım olarak bir sorumluluk aldıysak, yalnızca bize atanmış parçaya değil, ortaya çıkacak sonuca da bakmamız gerekiyor.

Ama burada önemli bir ayrım var.

Proaktif olmak, her işi üzerine almak değil.

Her problemi kendimiz çözmeye çalışırsak bir süre sonra hem odağımızı kaybederiz hem de takımın önünde bir darboğaz haline gelebiliriz.

Bazen proaktif davranmak problemi kendin çözmek değil, problemin çözülmesini sağlamak demek.

Bunu özellikle belirsizliğin yüksek olduğu işlerde daha fazla hissediyorum.

Yeni bir proje veya feature geldiğinde requirement’lar eksik olabilir, başka takımlara bağımlılıklar olabilir veya bazı teknik kararlar henüz alınmamış olabilir.

Böyle zamanlarda “Bunlar netleştiğinde başlayabiliriz.” deyip beklemek yerine belirsizliği biraz sahiplenmek gerekiyor.

Neler net değil? Hangi soruların cevaplanması gerekiyor? Kimlerle konuşmalıyız? Başka bir takımın desteğine ihtiyacımız var mı?

Bazen yapılması gereken tek şey doğru insanları bir araya getirmek oluyor.

Bütün cevapları bilmek gerekmiyor. Ama hangi soruların cevaplanması gerektiğini görebilmek çok şey değiştiriyor.

Proaktif bir insanı düşündüğümde aklıma gelen en basit cümle şu:

“Söylenmesini beklemeden yapılması gerekeni görebiliyor.”

4. Pragmatism — Mükemmel Olanı Değil, Doğru Olanı Seçebilmek

Yazılım geliştirirken çoğumuz yaptığımız işin mümkün olduğunca iyi olmasını istiyoruz.

Daha temiz bir mimari, daha güncel teknolojiler, daha iyi testler, daha az teknik borç…

Ama gerçek hayatta kararları yalnızca teknik doğrular üzerinden veremiyoruz.

Özellikle son dönemde üzerinde çalıştığım işlerde en sık karşılaştığım kısıtlardan biri zaman.

Yıllardır çalışan bir ürünü yeni teknolojilere dönüştürürken her parçayı en baştan kusursuz şekilde tasarlamak isteyebiliriz. Teknik açıdan bunun için birçok haklı sebebimiz de olabilir.

Ama bir taraftan ürünün de dönüşmeye devam etmesi gerekiyor.

Bu yüzden kendime sorduğum soru zamanla değişti:

“Bunu en mükemmel şekilde nasıl yapabiliriz?”

yerine:

“Elimizdeki zaman içerisinde ürünü güvenli, anlamlı ve sürdürülebilir şekilde nasıl ileri taşıyabiliriz?”

Ben pragmatizmi en çok böyle durumlarda düşünmeye başladım.

Pragmatik olmak kaliteyi önemsememek veya her zaman en hızlı çözümü seçmek değil. Hangi noktada kaliteden taviz veremeyeceğimizi, hangi noktada daha basit bir çözümün yeterli olduğunu ve bugün verdiğimiz kararın gelecekte bize neye mal olacağını görebilmek.

Bazen teknik olarak çok daha iyi bir çözümün hayata geçmesi aylar sürebilir. Daha basit bir çözüm ise ürünün birkaç hafta içerisinde anlamlı bir adım atmasını sağlayabilir.

Burada kendime sorduğum şey şu: Neyi kazanıyoruz, neyden vazgeçiyoruz ve bugün aldığımız karar yarın karşımıza nasıl çıkacak?

Bence iyi mühendislik her zaman en sofistike veya en kusursuz çözümü üretmek değil. Bazen koşulları doğru okuyup yeterince iyi olan çözümün gerçekten yeterli olduğu noktayı görebilmek.

Sonuçta geliştirdiğimiz teknoloji bir amaca hizmet ediyor. Ürünün, kullanıcının ve organizasyonun ilerlemesini sağlamıyorsa teknik olarak ne kadar kusursuz olduğunun tek başına çok fazla anlamı kalmıyor.

Pragmatizmi kendim için şöyle özetliyorum:

“Koşulları ve sonuçlarını anlayarak doğru trade-off’u yapabiliyor.”

5. Resourcefulness — Cevabı Bilmesen de Bir Yol Bulabilmek

Yazılım dünyasında kimsenin cevabını bilmediği problemlerle sık sık karşılaşıyoruz.

Daha önce kullanılmamış bir teknoloji, dokümantasyonu yetersiz bir sistem veya takımda kimsenin deneyimlemediği bir problem…

Ben de bu durumlarla birçok kez karşılaştım.

Böyle zamanlarda genellikle hızlıca bir şeyler denemeye çalışıyorum. Bulabildiğim örnekleri ve dokümantasyonları inceliyorum, küçük denemeler yapıyorum ve öğrendiklerimi mümkün olduğunca basit ve anlaşılır bir hale getirmeye çalışıyorum.

Bazen ortaya küçük bir proof of concept çıkıyor. Bazen basit bir kod örneği. Bazen de takımın kullanabileceği birkaç sayfalık bir dokümantasyon.

İlk hedefim mükemmel bir çözüm çıkarmak olmuyor.

Önce belirsiz olan şeyi, üzerine konuşabileceğimiz kadar somut hale getirmeye çalışıyorum.

Tabii ki her şeyi kendi başımıza çözmemiz gerekmiyor.

Konuyu bilmediğim durumlarda organizasyon içerisinde bunu bilebilecek insanları bulup onlarla konuşmanın bana çok şey kazandırdığını gördüm.

Ama burada sadece doğru kişiyi bulmak da yetmiyor.

Doğru soruyu sormak gerekiyor.

Neyi çözmeye çalıştığımızı gerçekten anlamadıysak doğru soruyu sormak da zorlaşıyor. Bu yüzden önce problemi anlamak, neyi bilmediğimizi fark etmek ve sonra doğru sorularla ilerlemek benim için önemli.

Bütün bunların arkasında ise çok basit bir şey olduğunu düşünüyorum:

Merak.

Yeni bir şey öğrenirken deneyiminin veya title’ının çok fazla önemi kalmıyor. Senior, Lead veya kariyerinin daha başında olabilirsin. Daha önce hiç karşılaşmadığın bir konu önüne geldiğinde hepimiz aynı yerden başlıyoruz:

Bilmiyoruz.

Zamanla şunu fark ettim: Asıl fark, cevabı bilmekten çok cevaba nasıl ulaşacağını bilmekte.

Araştırmak, denemek, doğru insanlara ulaşmak, doğru soruları sormak ve öğrendiklerimizi başkalarının da kullanabileceği kadar basit hale getirmek…

Resourcefulness’ı kendim için şöyle özetliyorum:

“Nasıl yapılacağını bilmese bile, nasıl ilerleyeceğini bulabiliyor.”

Daha Fazla Etki Yaratmak

Bu beş özelliği yan yana koyduğumda ortak bir noktada birleşiyorlar:

Credibility: Onun fikrine ve yaklaşımına güveniyorum.

Reliability: Ben orada olmasam bile ona güveniyorum.

Proactivity: Söylenmesini beklemeden yapılması gerekeni görebiliyor.

Pragmatism: Koşulları ve sonuçlarını anlayarak doğru trade-off’u yapabiliyor.

Resourcefulness: Nasıl yapılacağını bilmese bile, nasıl ilerleyeceğini bulabiliyor.

Bunların hiçbiri doğrudan kaç satır kod yazdığımızla ilgili değil. Ama hepsi çevremizdeki insanların ve takımın daha etkili olmasına katkı sağlıyor.

Bence team multiplier olmanın özü de burada.

Her problemi çözen kişi olmak, her kararın içinde bulunmak veya her toplantıya katılmak değil.

Bazen takım arkadaşının önündeki engeli kaldırmak. Bazen fikrini söyledikten sonra geri çekilip kendi kararını vermesine izin vermek. Bazen zor bir anda “Beraber çözeriz.” diyebilmek.

Bazen henüz problem haline gelmemiş bir şeyi fark etmek, mükemmel çözümden vazgeçip o an için doğru çözümü seçmek veya hiçbirimizin cevabı bilmediği bir konuda ilk adımı atmak.

Bunların birçoğu GitHub contribution grafiğinde görünmüyor. Ama takımın başarısı üzerinde yazdığımız birçok satır koddan daha büyük bir etki yaratabiliyor.

Kariyerimizin başlarında kendimize sıklıkla şu soruyu soruyoruz:

“Nasıl daha iyi bir developer olabilirim?”

Belki kariyerimizin bir noktasından sonra bu sorunun yanına başka bir soru daha eklemek gerekiyor.

“Bugün ne kadar iş yaptım?”

yerine:

“Bugün çevremdeki insanların daha etkili olmasına nasıl katkı sağladım?”

Belki de bireysel katkıdan team multiplier olmaya geçiş tam olarak bu soruyla başlıyor.

Çünkü kariyerimizin bir noktasından sonra gelişmek yalnızca daha zor problemleri çözebilmekten geçmiyor. Bazen başkalarının o problemleri çözebilmesini sağlamaktan geçiyor.

Bazen de başarı birimini değiştirmek gerekiyor:

Kendimizden, takımımıza.

Çünkü bir sonraki seviye her zaman daha iyi kod yazmak değil.

Daha fazla etki yaratmak.

Daha İyi Kod Yazmak Değil, Daha Fazla Etki Yaratmak was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mesaj Broker’a Ulaştı, Peki Ya Consumer İşleyemezse?

Consumer tarafında başarısız olan mesajların kontrollü şekilde nasıl yeniden denendiğini, retry mekanizmalarının nasıl tasarlandığını ve kalıcı hataların DLQ ile nasıl yönetildiğini ele alıyoruz.

Yazı serimizin ilk bölümünde Publisher’ın mesajı Broker’a güvenilir şekilde ulaştırması sağlamış, ikinci bölümünde ise duplicate mesajların consumer tarafında idempotency ile kontrol altına alınmasını sağlamıştık. Dolayısıyla Publisher → Broker → Consumer akışını temel olarak tamamlamıştık

Yazı serimizin son bölümü olacak olan bu bölümde ise “consumer aldığı mesajları işleyemezse ne olur?” sorusuna cevap bulmaya çalışacağız.

1. Consumer Mesajı İşleyemezse Ne Olur?

Consumer’lar her zaman istediğimiz şekilde çalışmayabilir. Bazen database’e olan erişim geçici olarak kesilebilir, bazen ilgili consumer’ın kullandığı harici servis cevap vermeyi durdurabilir veya network kaynaklı çeşitli problemler yaşanabilir.

Örneğin:

• Database kısa süreliğine erişilemez durumda olabilir.
• Harici bir API timeout verebilir.
• Network problemi yaşanabilir.
• Consumer içerisinde beklenmeyen bir exception oluşabilir.

Bu gibi durumlarda mesajın kendisinde herhangi bir problem olmayabilir. Problem yalnızca consumer’ın mesajı o anda sağlıklı şekilde işleyememesidir. Dolayısıyla böyle bir mesajı doğrudan kaybetmek veya tamamen başarısız kabul etmek yerine, bir süre sonra tekrar işlenmesini isteyebiliriz.

Örneğin database’e erişim 10 saniyeliğine kesilmişse, aynı mesaj birkaç saniye sonra tekrar işlendiğinde işlem başarılı olabilir. Benzer şekilde geçici olarak cevap vermeyen bir harici servis kısa bir süre sonra tekrar kullanılabilir hale gelebilir.

Bu nedenle mesajlaşma sistemlerinde başarısız olan bir işlemi belirli kurallar çerçevesinde yeniden denemek isteyebiliriz.

İşte bu yeniden deneme yaklaşımına Retry diyoruz. Fakat burada yeni bir soru ortaya çıkıyor:

Mesaj başarısız olduğu anda tekrar denenmeli mi?

İlk bakışta mantıklı görünen bu yaklaşım, bazı durumlarda sistemi daha da probleme sokabilir.

2. Retry Nedir ve Neden Immediate Retry Her Zaman Doğru Değildir?

Retry, başarısız olan bir işlemin belirli koşullar altında tekrardan denenmesidir. RabbitMQ tarafında da bir mesaj sağlıklı şekilde işlenemediğinde bu mesajın consumer’a tekrardan ulaştırılmasını sağlamak için ilgili mesajı queue’ya göndeririz. Queue’ya geri gönderilen mesajlar tekrardan consumer’lara iletilir.

Bunu en basit şekilde alttaki kod örneği ile gerçekleştirebiliriz:

await channel.BasicNackAsync( 
  deliveryTag: args.DeliveryTag, 
  multiple: false, 
  requeue: true);

Burada ‘requeue: true’ dediğimizde, consumer’a iletilen mesajın tekrardan queue’ya yazılmasını istediğimizi belirtiyoruz. Böylece bu mesaj, o an consumer tarafından işlenemese dahi tekrardan queue’ya yazılarak bir süre sonra consumer tarafından işlenebilir hale gelecektir. Bu akışı daha anlaşılabilir hale getirmek adına alttaki görseli inceleyebiliriz.

Bu görselde anlayacağımız üzere queue’daki mesaj consumer’a iletiliyor fakat bir exception yaşandığından dolayı ilgili mesaj NACK ile birlikte requeue ediliyor. İlgili mesajın NACK edilmesi ‘Requeue : true’ parametresi ile yapıldığı için mesajı tekrardan queue’ya koyuyoruz.

Requeue edilen mesaj queue’dan consumer’a tekrardan iletiliyor. Bu sırada consumer’ın kullandığı dış servis sağlıklı şekilde çalışmaya başladığı için ilgili mesaj başarıyla işleniyor.

Peki, ya consumer uzun bir süre sağlıklı şekilde çalışamazsa ne olacak? Bu süreç içerisinde broker ve consumer arasındaki trafik nasıl olacak?

İsterseniz şöyle bir kurgumuz olsun:

Queue’da hazır olarak bekleyen 10.000 mesajımız olsun ve bu mesajlar consumer tarafından tüketiliyor olsun. İlgili consumer’ın bir dış servise bağımlılığı olduğunu ve bu dış servisin 5 saniyeliğine erişilemez durumda olduğunu farzedelim.

Bu 5 saniyelik süreçte broker ve queue arasında nasıl bir etkileşim olacak?

Üstteki görselde neler olacağını temsil etmeye çalıştım. Sizin de göreceğiniz üzere bu 5 saniyelik süreçte broker tarafından queue’ya toplamda 60.000 mesaj gönderilmiş. Aynı şekilde consumer tarafından broker’a da 60.000 mesajın requeue edilmesi bildirilmiş.

Bu 5 saniyelik süreçte, consumer’ın dış servis bağımlılığında bir problem olmasına rağmen sistemdeki component’lar gereksiz yere işlemler yapıyor, CPU tüketiyor, hatalar fırlatıyor ve loglar üretiyor. Kısacası kaynaklarımız bu durumdan ciddi şekilde etkileniyor.

Bu örnekte, consumer’ın mesajı işleyemediği durumlarda mesajı direkt requeue etme işleminin verimli olamayabileceğini gözlemliyoruz.

Peki burada ne yapabiliriz diye düşünecek olursak aklımıza ilk gelen fikir muhtemelen şu olacaktır:

“Bu kadar sık denemek yerine daha geniş aralıklar ile deneyelim.”

İsterseniz bu fikri, yani ‘Delayed Retry’ı inceleyerek devam edelim.

3. Delayed Retry, TTL ve Dead Letter Exchange

Bir önceki bölümde, consumer’ın işleyemediği mesajların doğrudan requeue edilmesinin her zaman sağlıklı bir yaklaşım olmadığını gördük. Özellikle problemin birkaç saniye boyunca devam ettiği durumlarda mesajların sürekli olarak consumer’a iletilmesi, işlenememesi ve tekrar queue’ya alınmasının sistem üzerinde gereksiz kaynak tüketimine sebep olabileceğinden de bahsetmiştik.

Delayed Retry’da yapmak istediğimiz şey oldukça basit:

Başarısız olan mesajı hemen tekrar denemek yerine, belirli bir süre beklettikten sonra tekrar deneyelim.

İsterseniz test sonucunda iki farklı retry yöntemini karşılaştırabilmek adına yine aynı örnek ile devam edelim. Requeue durumunda mesajı tekrar consumer’a göndermek yerine 5 saniye bekletip tekrar deneyelim.

Üstteki görselden de akışımızı anlayabiliriz.

Burada dikkat ederseniz immediate retry yaklaşımından farklı olarak başarısız olan mesajı doğrudan ana queue’ya geri göndermiyor, ayrı bir retry queue’ya yönlendiriyoruz.

Bu noktada anlamlandıramadığımız 2 farklı soru olabilir.

1. Neden ayrı bir queue kullandık?

2. Mesajın queue içerisinde kaç saniye duracağını nasıl tanımlıyoruz?

Bu sorulara verilecek cevapların temelini oluşturacak olan TTL (Time To Live) kavramı ile devam etmek istiyorum. Bu kavramın ne olduğunu ve nasıl çalıştığını anladığımızda üstteki sorulara doğrudan kendimiz cevap verebilir hale geleceğiz.

TTL Nedir?

TTL, bir mesajın queue içerisinde ne kadar süre tutulabileceğini belirlememizi sağlar. TTL dolduğunda ilgili mesaj queue’dan silinebilir hale gelir.

TTL değerini iki farklı kapsam da tanımlayabiliriz.

Bunlardan ilki, mesaj başına TTL tanımlaması yapmaktır. Bu yaklaşımda her bir mesaja ayrı bir TTL değeri atanır ve ilgili mesajların ömrü o TTL değeri kadardır.

Örneğin bir mesajın TTL değerini ‘5000 ms’ saniye olarak atadığımızda, 5 saniye sonra bu mesaj queue’dan silinebilir hale gelecektir.

Not: TTL süresi dolan mesajlar queue’dan direkt silinmez. Queue’nun başında yapılacak olan TTL kontrolü sonrasında silinirler. Dolayısıyla “TTL süresi biten bir mesajlar queue’dan direkt silinir” demek çok doğru değil.

Bir diğer tanımlama şeklimiz de queue bazlı TTL tanımlaması yapmaktır. Bu yaklaşımda ise her bir queue’ya, içereceği mesajların ne kadar ömrü olacağı en baştan tanımlanır. Dolayısıyla bu tür queue’lara mesajlar gönderildiğinde, o mesajların TTL değerleri aslında queue’nun TTL değeri olacaktır.

Bu görselden de hatırlayacağımız üzere “5s-retry-queue” sunda ilgili queue nun TTL değerini 5 saniye olarak ayarlamıştık. Böylece mesajların 5 saniye sonra retry queue’dan silinmesini sağlamıştık.

Tamam, TTL’in iki şekilde tanımlandığını gördük. TTL süresi dolan mesajlar queue’dan silinecekti. Peki TTL değeri dolduğundan dolayı queue’dan silinen mesajlar nereye gidecek?

Bizim istediğimiz şey mesajın silinmesi değil.

Amacımız mesajı bir süre beklettikten sonra tekrar ana queue’ya göndererek consumer tarafından yeniden işlenmesini sağlamak.

Tam olarak bu noktada mesajların ana queue’ya yönlendirilmesinde önemli rol alacak Dead Letter Exchange devreye giriyor.

Dead Letter Exchange

RabbitMQ’da bir mesaj belirli nedenlerden dolayı bulunduğu queue’dan çıkarıldığında, mesaj başka bir exchange’e yönlendirilebilir.

Bu exchange’e Dead Letter Exchange, yani kısaca DLX denir. Bu exchange’e yönlendirilen mesajlar da ilgili routing key değeri ile birlikte ilgili queue’ya yönlendirilir.

Böylece akışımız şu hale gelir:

order-created-queue
    ↓
consumer
    ↓
  fail
    ↓
5s-retry-queue
    ↓
 TTL = 5s
    ↓
   DLX
    ↓
order-created-queue
    ↓
consumer

İsterseniz burada biraz duralım ve ilk baştaki örneğimizi düşünelim. Bizim istediğimiz şey tam olarak şuydu :

“ Mesajlar direkt requeue olmasın, 5 saniye bekledikten sonra requeue olsun”.

O zaman kendi kendimize şu çıkarımı yapabiliriz: “Biz de consumer olarak bir mesajı işleyemediğimizde direkt requeue etmek yerine, o mesajı bir retry-queue’ya publish edelim. Retry-queue’ya gönderilen mesaj TTL’i dolana kadar beklesin. TTL dolduğunda mesajı, o queue’da DLX olarak tanımlanmış olan order-created-exchange’e yönlendirelim. Böylece işleyemediğim her bir mesaj 5 saniye bekledikten sonra tekrardan queue’ya yönlendirilsin.”

Farkettiyseniz bu noktaya kadar TTL ve DLX’in ne olduğunu öğrendik. Sonrasında ise öğrendiklerimizle üstteki çıkarımı yapabildik.

Dolayısıyla TTL’i anlatırken kendi kendimize sormuş olduğumuz şu iki soruyu kendimiz cevaplamış olduk :

1. Neden ayrı bir queue kullandık?

2. Mesajın queue içerisinde kaç saniye duracağını nasıl tanımlıyoruz?

Yazımızın bu noktasına kadar Immediate Retry’ın ne olduğunu ve ne gibi etkiler yaratabileceğini gördük. Yarattığı etkileri azaltmak için de Delayed Retry yaklaşımını kullandık.

Her iki yaklaşımın da temel amacı, o anda sağlıklı şekilde işlenemeyen bir mesajın daha sonra tekrar işlenebilmesini sağlamaktır.

Buradaki varsayımımız oldukça basit:

Consumer’ın veya bağımlı olduğu servisin yaşadığı problem geçici olabilir.

Peki problem geçici değilse?

Consumer 5 saniye sonra da, 10 saniye sonra da, 1 dakika sonra da aynı mesajı işleyemiyorsa ne olacak?

Queue çok fazla mesaj alıyor fakat bu mesajlar işlenemiyor.

Üstteki senaryoda queue’ya yoğun şekilde mesaj gelmeye devam ederken consumer bu mesajları başarılı şekilde işleyemiyor. Başarısız olan mesajlar retry mekanizması üzerinden tekrar dolaşıma giriyor.

Consumer’ın sağlıklı şekilde hizmet veremediği süre uzadıkça işlenmeyi bekleyen ve tekrar denenen mesajların sayısı da artmaya devam ediyor.

Dolayısıyla yalnızca retry mekanizması oluşturmak yeterli değildir.

Bir noktada şu soruya cevap vermemiz gerekir:

Bir mesajı kaç defa retry edeceğiz?

Çünkü başarısız olan bir mesajı sonsuza kadar tekrar denemek yerine, belirli bir deneme sayısından sonra normal akıştan çıkarmamız gerekir.

Bu noktada karşımıza Retry Count, maksimum deneme sayısı ve başarısız mesajları ayrı bir yerde tutmamızı sağlayacak Dead Letter Queue kavramları çıkıyor.

4. Retry Count, Maksimum Deneme ve Dead Letter Queue

Bir önceki bölümde kendi kendimize şu soruyu sormuştuk:

Bir mesajı kaç defa retry edeceğiz?

Aslında bu sorunun cevabı oldukça önemli. Çünkü mesajın her başarısız olduğunda tekrar tekrar dolaşıma sokulması, bir noktadan sonra retry mekanizmasının kendisinin problem haline gelmesine sebep olabilir.

Örneğin bir consumer’ın işleyemediği bir mesajın döngüsü alttaki gibi olacaktır.

Message
   ↓
Consumer
   ↓
Fail
   ↓
Retry #1
   ↓
Fail
   ↓
Retry #2
   ↓
Fail
   ↓
Retry #3
   ↓
Fail
   ↓
...

Burada fark edeceğiniz üzere retry mekanizmasının ne zaman sonlanacağına dair herhangi bir kuralımız yok. Bu yüzden bu döngü sonsuza kadar devam edecektir. Bu döngünün belirli bir süre sonra sonlanması için ilk yapmamız gereken şeylerden biri, ilgili mesajın daha önce kaç defa retry edildiğini bilebilmek.

Retry Count

Retry Count, bir mesajın kaç defa yeniden işlenmeye çalışıldığını takip etmemizi sağlar.

RabbitMQ, mesajın header’ına “x-death” bilgisini ekler. Bu bilgi içerisinde ilgili mesajın hangi queue’dan, hangi sebeple ve kaç defa dead-letter edildiği gibi bilgileri içerir.

Bu bilgi ile birlikte consumer mesajı her aldığında, ilgili mesajın daha önce kaç defa retry edildiğini bilebilir hale gelir.

Maksimum Retry Sayısı

Bazı durumlarda mesajların sağlıklı şekilde işlenememesi geçici bir durumdur. Şuanda işlenemeyen mesaj 1 saniye sonra sağlıklı şekilde işlenebilir. Bazı durumlarda ise ilgili mesaj uzun sürelerce işlenemeyebilir.

Mesajın uzun süre boyunca işlenememesinin component’larımız üzerinde oluşturacağı etkiyi engellemek için retry mekanizmalarında bir maksimum retry sayısı belirleyebiliriz.

Örneğin uygulamamızda şu şekilde bir kural tanımladığımızı düşünelim:

Max Retry Count = 3

Bu durumda sağlıklı bir şekilde işlenemeyecek olan mesajın akışı şu şekilde olacaktır:

İlk İşleme
   ↓
Fail
   ↓
Retry #1
   ↓
Fail
   ↓
Retry #2
   ↓
Fail
   ↓
Retry #3
   ↓
Fail

Mesaj üçüncü retry sonrasında hâlâ başarılı şekilde işlenemiyorsa artık şu soruyu sormamız gerekir:

Bu mesajı bir kez daha retry etmenin bize gerçekten bir faydası var mı?

Bazı durumlarda cevap evet olabilir; fakat belirlediğimiz retry politikasına göre bu noktada artık mesajın normal retry döngüsünden çıkarılması gerekir.

Çünkü aksi durumda başarısız olan mesaj sürekli olarak:

Queue → Consumer → Fail → Retry Queue → Queue

döngüsünde dolaşmaya devam eder.

Bu durum yalnızca kaynak tüketimini artırmakla kalmaz, aynı zamanda gerçekten işlenebilir mesajların da aynı altyapıyı paylaşmasına sebep olur. Aynı altyapıyı paylaşan bir yapıda belki hiç işlenmeyecek mesajlar, işlenebilecek mesajların önüne geçip ilgili mesajların daha geç işlenmesine de sebebiyet verebilir. Dolayısıyla bir mesajın kaç defa retry edilebilir olduğunun sınırlandırılmasının bize birden fazla yararının olacağını görebiliyoruz.

Bu zamana kadar consumer tarafında yaşanan bir problemden dolayı işlenemeyen mesajları retry mekanizmamız ile tekrardan döngüye sokarak işlenebilmesini sağladık.

Peki mesajlarımızın işlenememesini sebebi consumer değil de mesajın bizzat kendisiyse?

Örneğin mesajın payload’ında bir problem varsa, zorunlu bir alan eksikse veya ilgili business rule mesajın işlenmesine izin vermiyorsa aynı mesajı 10 defa da, 100 defa da retry etsek sonuç büyük ihtimalle değişmeyecektir.

Dolayısıyla problemin ana nedeni mesajın kendisi olduğu durumlarda, ilgili mesajın retry edilmesinin bir mantığı olmayacaktır.

O zaman bu mesajı ne yapacağız, mesajın kendisinde hata varsa bu mesaj direkt yok mu sayılmalıdır? Tabii ki hayır.

Bu mesaj bizim için hala önemli olabilir. Mesajın neden işlenemediğini incelemek, loglarla karşılaştırmak veya problem giderildikten sonra tekrar işlemek isteyebiliriz. Bu sebeple bu gibi problem yaşayan mesajları Dead Letter Queue adını verdiğimiz queue’larda tutabiliriz.

Dead Letter Queue Nedir?

Dead Letter Queue, normal mesaj akışı içerisinde başarılı şekilde işlenemeyen mesajları ayrı bir yerde tutmak için kullandığımız queue’dur.

Örneğin akışımızı şöyle kurgulayabiliriz:

order-created-queue
        ↓
     consumer
        ↓
      fail
        ↓
   retry-queue
        ↓
     retry #1
        ↓
      fail
        ↓
     retry #2
        ↓
      fail
        ↓
     retry #3
        ↓
      fail
        ↓
       DLQ

Böylece belirlediğimiz maksimum retry sayısından sonra mesaj artık tekrar tekrar normal akışa dahil edilmez.

Bunun yerine ayrı bir queue içerisinde tutulur.

Örneğin:

order-created-dead-letter-queue

şeklinde bir queue tanımlayabiliriz.

Bu queue içerisinde bulunan mesajlar artık bizim için şu anlama gelir:

“Bu mesaj normal retry mekanizması ile başarılı şekilde işlenemedi. İncelenmesi gerekiyor.”

İncelenmesi gerektiğini düşündüğümüz mesajlar dead-letter-queue vesilesiyle daha sonra inceleyebilir, hataları düzeltip tekrardan publish edebiliriz.

Yazımınızın bu noktasına kadar öğrendiklerimizle artık:

• Mesaj başarısız olduğunda retry edebiliyoruz.
• Retry işlemini belirli aralıklarla gerçekleştirebiliyoruz.
• Kaç defa retry edildiğini takip edebiliyoruz.
• Belirli bir limitten sonra mesajı DLQ’ya gönderebiliyoruz.

Şuanda geldiğimiz noktanın gayet iyi olduğunu düşünüyorum. İlk versiyonumuzda immediate retry ile birlikte çokça retry yapıyorduk. Sonrasında delayed retry ile birlikte bu retry etme sıklığını genişleterek kaynak tüketimini azalttık. Bununla birlikte mesajların retry edilmesini sınırlandırarak işleyenemeyecek olan mesajları main queue’dan çıkartıp ayrı bir queue’da muhafaza ettik.

İsterseniz şuandaki yapımızı biraz daha inceleyelim.

Maksimum retry sayısının 3 olduğu ve Delayed Retry kullandığımız bir senaryoda yaşanan olası problem 15 saniye içerisinde çözüldüğü takdirde ilgili mesaj başarıyla işlenebiliyor.

5 saniye
5 saniye
5 saniye

Problem 30 saniye içerisinde çözülecekse ne yapacağız?

Şuandaki çözüm yöntemimize göre mesajımız dead-letter-queue’ya gidecek ve bizim manuel olarak ilgili mesajı tekrardan publish etmemiz gerekecek değil mi?

Burada nasıl bir çözüm yöntemi uygulayabiliriz diye düşünelim ve aklımıza gerçek hayattan şu senaryoyu getirelim:

“Birisini telefonla arayıp ulaşamadığımızda tekrardan ararız, yine ulaşamazsak biraz bekler sonrasında ararız. Eğer tekrardan ulaşamazsak şansımızı saatler sonrasında deneriz.”

Gerçek hayatta uyguladığımız bu çözüm yöntemini burada da uygulabilir miyiz ?

İşte bu düşünce bizi Exponential Backoff yaklaşımına götürüyor.

5. Exponential Backoff ve Jitter

Exponential Backoff, her başarısız retry denemesinden sonra bir sonraki deneme için beklenecek sürenin kademeli olarak arttırılması yaklaşımıdır.

Örneğin retry sürelerimizi şu şekilde belirlediğimizi düşünelim:

Retry #1 → 5 saniye
Retry #2 → 10 saniye
Retry #3 → 20 saniye

Burada mesaj her başarısız olduğunda aynı süre boyunca beklemek yerine, bir sonraki retry için daha uzun süre bekliyor.

Akışımız kabaca şu şekilde olur:

Message
   ↓
Consumer
   ↓
Fail
   ↓
5 saniye bekle
   ↓
Retry #1
   ↓
Fail
   ↓
10 saniye bekle
   ↓
Retry #2
   ↓
Fail
   ↓
20 saniye bekle
   ↓
Retry #3

Aslında burada yaptığımız şey, bir önceki bölümde verdiğimiz telefon örneğinin karşılığıdır.

Örneğimiz şuydu:

İlk denemede ulaşamadığımızda kısa bir süre bekleriz. Tekrar ulaşamazsak bu sefer biraz daha uzun bekleriz. Başarısızlık devam ettikçe denemelerimizin arasındaki süreyi arttırırız.

Exponential Backoff yaklaşımında da temel düşünce aynı.

Bu yaklaşım ile hem consumer’ın bağımlı olduğu servise toparlanması için daha fazla zaman tanıyoruz hem de sürekli aynı sıklıkta retry yaparak sistemi gereksiz şekilde yormamış oluruz.

Bekleme süresini alttaki mantığa göre hesaplayalım

delay = baseDelay × 2^retryCount

Örneklerimizde baseDelay’i 5 saniye olarak kullanmıştık, burada da aynı değer ile devam edelim:

Retry #0 → 5 × 2⁰ = 5 saniye
Retry #1 → 5 × 2¹ = 10 saniye
Retry #2 → 5 × 2² = 20 saniye
Retry #3 → 5 × 2³ = 40 saniye

Tabii ki bu sürenin sonsuza kadar büyümesini de istemeyiz. Retry sayımız düşük oluğunda retry süresi ile ilgili bir problem olmayabilir. Retry sayısı eğer artarsa bu süre için üst sınır tanımlamak isteyebiliriz.

Örneğin:

5s → 10s → 20s → 40s → 60s → 60s

şeklinde bir üst sınır koyabiliriz.

Burada retry sürelerini nasıl belirlediğimizi gördük. Peki bunu nasıl uygulayabiliriz biraz buna bakalım.

Hatırlayacağınız üzere Delayed Retry yaklaşımında 1 adet retry-queue’muz vardı ve bu queue ile 5 saniyelik gecikme sağlıyorduk. Exponential Backoff yaklaşımında ise sahip olmamız gereken queue sayısı, maksimum retry sayısı ile doğrudan ilişkilidir. Maksimum retry sayımızı 3 olarak belirlersek 3 farklı retry süremiz olmalı. Bu süreler de 5, 10 ve 20 olacaktır. Bu sebeple 3 farklı retry süresi için 3 adet retry queue’su oluşturacağız.

Bu senaryoda Consumer kendisine iletilen mesajın kaç defa retry edildiğine göre o mesajı ilgili retry-queue’lara publish edecek. Retry-queue’ların da dead-letter-exchange’leri order-created-exchange olduğu için mesajlar TTL sonunda ana queue’mıza yönlendirilecektir.

Exponential Backoff yöntemimizde temel olarak bu şekildeydi. İsterseniz bu 3 farklı yöntemin broker-consumer arasındaki trafiğe nasıl etki ettiğini gözlemlerek devam edelim.

Immediate Retry’da bekleme sürecinde broker-consumer arasındaki iletişim şu şekildeydi:

Görüldüğü üzere 30 saniyelik bir kesintide onlarca mesaj döngüsü oluşuyor.

Delayed Retry’a baktığımızda ise:

Burada ise Immediate Retry’daki sıkı retry işlemlerinin biraz daha azaltılmış halini görüyoruz. Immediate retry’a göre kaynakların daha iyi kullanıldığı bir yöntem olduğunu düşünüyorum.

Son olarak da Exponential Backoff kullandığımız retry’a bakalım:

Exponential Backoff ta ise broker ile consumer arasında sadece 4 adet cycle oluşmuş. Kaynakların en verimli şekilde kullanıldığı yöntemin bu olduğunu görebiliriz.

Üç yaklaşımı da alttaki görselden çok daha iyi inceleyebiliriz.

Bu üç yöntemde de broker-consumer arasındaki döngü sayılarının nasıl değiştiğini ve bu değişimin kaynaklarımızı nasıl etkileyebileceğini gördük.

Bu noktada dikkat çekmek istediğim bir konu var.

Dikkat edersek şimdiye kadar kullandığımız retry yaklaşımlarında mesajlarımızın büyük bir kısmı belirli zamanlarda toplu şekilde tekrar publish ediliyor.

Örneğin elimizde 10.000 mesaj olduğunu düşünelim. Bu mesajların tamamı aynı anda başarısız olduysa ve aynı retry süresine sahipse, 10 saniye sonra bu 10.000 mesajın tamamı tekrar aynı anda dolaşıma girecektir.

Peki böylesine büyük bir yükün tek bir anda sisteme geri dönmesi sizce bizi nasıl etkiler?

Thundering Herd Problem

Bir retry zamanı geldiğinde binlerce mesajın aynı anda tekrar publish edildiğini düşünelim. Bu mesajların tamamı kısa bir zaman aralığında consumer’lara ulaşmaya başlayacaktır.

İlk bakışta bunda bir problem yokmuş gibi görünebilir. Sonuçta amacımız zaten mesajları tekrar işlemek.

Fakat binlerce mesajın aynı anda consumer’lara ulaşması, sistem üzerinde ani bir yük oluşturabilir. Consumer tarafında CPU kullanımı artabilir, database’e veya harici servislere aynı anda çok sayıda istek gönderilebilir. Eğer problemimizin sebebi zaten kaynakların yoğun şekilde kullanılmasıysa binlerce mesajı retry etmemiz problemli olan yapıya bir darbe daha vurabilir.

Bahsettiğimiz problemli döngünün akışı şu şekilde:

Servis yoğunlaştı
        ↓
Mesajlar başarısız oldu
        ↓
Belirli bir süre beklendi
        ↓
Binlerce mesaj aynı anda retry edildi
        ↓
Servis tekrar yoğunlaştı
        ↓
Mesajlar tekrar başarısız oldu

Burada kaynaklarımızı sıkıntıya sokan problem Thundering Herd Problemidir.

İsterseniz bir diğer olan Jitter bölümünde bu problemi çözmeye çalışalım.

Jitter

Bir önceki bölümde gördüğümüz üzere problem, yalnızca retry işlemi yapmak değil; çok sayıda mesajın aynı anda retry edilmesiydi.

Örneğin 10.000 mesajın tamamının 5saniye sonra tekrar işlenmek üzere beklediğini düşünelim.

Bu durumda Exponential Backoff kullanıyor olsak bile bütün mesajlar aynı bekleme süresine sahip olduğu için sistem üzerinde yine ani bir yük oluşabilir.

İşte Jitter yaklaşımında yapmak istediğimiz şey, hesaplanan retry süresine küçük miktarda rastgelelik eklemektir.

Örneğin normalde retry süremiz 5 saniye olsun. Jitter uyguladığımızda bu süre şu aralıkta olur:

4.5 - 5.5 saniye

Böylece aynı anda başarısız olan mesajların tamamı tam olarak 5. saniyede tekrar işlenmek yerine farklı zamanlarda retry edilir.

Örneğin:

Message #1 → 4.6 saniye
Message #2 → 4.9 saniye
Message #3 → 5.2 saniye
Message #4 → 5.4 saniye

şeklinde farklı bekleme süreleri oluşabilir.

Bu sayede bütün retry işlemlerini tek bir ana yığmak yerine zamana yaymış olur ve kaynaklarımızı daha iyi bir şekilde tüketmiş oluruz.

Jitter’ı Exponential Backoff ile birlikte düşündüğümüzde ise şöyle bir yapı elde edebiliriz:

Retry #1 → 4.5 - 5.5 saniye
Retry #2 → 9.5 - 10.5 saniye
Retry #3 → 19.5 - 20.5 saniye

Burada Exponential Backoff ile birlikte her başarısız denemeden sonra bekleme süresini artırırken; Jitter ile de bu süreye küçük bir rastgelelik ekleyerek mesajların aynı anda retry edilmesini azaltmaya çalıştık. Gün sonunda sistem üzerindeki ani yükü azalttık, consumer’ların ve daha kontrollü şekilde trafik almasını sağladık diyebiliriz.

Bu yazı serisinde RabbitMQ öğrenme sürecimde merak ettiğim ve öğrenmekten keyif aldığım başlıkları yazıya dökmek istedim. Umarım bilgilendirici bir yazı serisi olmuştur.

İyi okumalar dilerim.

RabbitMQ Reliability — Part 3: Retry, DLQ, Exponential Backoff & Jitter was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

Publisher Confirm Sonrasında Güvenilirliği Sürdürmek

Güvenilir mesajlaşmada duplicate mesajların neden kaçınılmaz olabileceğini, consumer tarafında nasıl güvenli işlendiğini ve Outbox ile veri tutarlılığının nasıl korunduğunu ele alıyoruz.

Bu serinin ilk bölümünde, temel bir mesajlaşma altyapısı kurup publisher ile broker arasında mesaj gönderiminin nasıl güvenli şekilde yapılabileceği ile ilgili konuşmuş, çeşitli örnekler ile de konuştuklarımızı deneyimlemiştik. Bahsettiğimiz güvenli iletişimi sağlamak için çeşitli yaklaşımlar kullanıp güvenli iletimi sağlamıştık. Yazımızın ikinci bölümünde ise, benimsediğimiz yaklaşımların nelere sebep olabileceği ile ilgili konuşacağız. Devamında da bu etkileri nasıl ortadan kaldırabileceğimiz hakkında çeşitli yaklaşımlar öğreneceğiz.

İsterseniz vakit kaybetmeden devam edelim.

1. Part 1’den Part 2’ye: Reliable Publish Neden Duplicate Mesaj Üretebilir?

Hatırlayacağınız üzere, güvenli iletişimi sağlayabilmek adına mesajlarımızı takip ediyor, broker’dan gönderilen ACK/NACK bildirilerine göre mesajların iletim durumları hakkında bilgi sahibi oluyorduk. Buna ek olarak herhangi bir connection fail durumunda mesajlarımızın iletim durumlarının başarılı yada başarısız olup olmadığı ile ilgili kesin bir kanıya varamayacağımız için bu mesajları tekrardan broker’a publish ediyorduk. Böylece her bir mesajımızın broker’a en az bir kere iletildiğinden emin olduğumuz bir yapıyı kurgulamıştık.

Mesajların en az bir kez iletilmesini bizim başarı kıstasımızdı. Peki ya birden fazla kez iletilirse?

İsterseniz alttaki akış ile bunu canlandıralım:

Gördüğümüz üzere broker’a bir mesaj iletildi, broker da bu mesajı başarılı şekilde alıp ACK bildirisini publisher’ın dinlemesi için yayınladı. Bu sırada bağlantı koptuğu için ACK bildirisi publisher’a iletilemediğinden dolayı publisher tarafı #1 mesajının durumu hakkında bilgiye sahip olamadı.

Her mesajın en az bir kez broker’a iletilmesi gerektiğinden dolayı aynı mesaj tekrardan broker’a üstte görüldüğü üzere iletildi. Mesajın republish edilmesi ile birlikte, publisher kendi sorumluluğı olan ‘at least one delivery ’i tamamlamış oldu. Peki bunu yaparken nelere sebebiyet verdi?

Duplicate Delivery.

Gördüğümüz üzere artık queue’da aynı mesajdan 2 adet var. Peki aynı mesajdan iki adet olması bizim istediğimiz bir şey mi?

Tabii ki de değil.

Bazen bir yeri düzeltmek isterken başka yerleri kaçınılmaz şekilde etkileyebiliyoruz. Mesajlarımızın güvenilir şekilde iletilmesi için bir yaklaşım ortaya koyduk, fakat bu bizi bambaşka bir şekilde etkiledi.

Bize olan etkisini görmek istersek şu örneğe bakabiliriz:

Az önce queue’ya order-created mesajını istemeyerek de olsa iki kopya şeklinde yazmıştık. Bu mesajlar consumer tarafından alındı ve kullanıcının uygulamasına ‘siparişiniz oluşturuldu’ bildiriminin iki defa gönderilmesine sebebiyet verdi. Siz müşteri olsaydınız ne düşünürdünüz?

Ben sipariş geçmişime bakıp ‘acaba yanlışlıkla iki defa sipariş mi verdim?’ diye bakardım.

Bu verdiğim örnek sadece customer’ı endişelendiren, belki de çok önemli olmayan bir örnek. Peki ya bu duplicate message bizim tutarlılığımızı etkileseydi ne olurdu? Belki de geri döndüremeyeceğimiz şeylere yol açacaktı.

Peki burada biz nasıl bir şey olsun isterdik bunu düşünelim.

Aynı mesajdan iki tane var ise, ben birini işlerim, diğerini de pas geçerim. Böylece mesajların duplicate olması beni etkilemez.

Böyle bir çözüm yolu aslında idempotent olmanın ta kendisidir.

Idempotency kelimesinin kökeni aslında matematikten geliyor. Latince “idem” kelimesi “aynı” anlamına gelirken, “potent” ise “etkili” anlamına geliyor, ikisini birleştirince de “aynı etkiye sahip” anlamı çıkıyor.

Idempotency’in ne olduğu ve nasıl kullanıldığı ile ilgili daha geniş bir anlatım isterseniz ilgili yazıma göz atabilirsiniz.

Lafın kısası, duplicate message oluşmasını her zaman engelleyemeyebiliriz; fakat consumer’larımızı idempotent tasarlayarak aynı mesajın birden fazla kez işlenmesinin sistemimiz üzerindeki etkisini ortadan kaldırabiliriz.

2. Idempotent Consumer Nedir ve Nasıl Tasarlanmalıdır?

Idemponent consumer, aynı mesaj birden fazla kez kendisine ulaştığında bu mesajın oluşturacağı iş etkisini yalnızca bir kez gerçekleştiren consumer’dır.

Aslında buradaki temel fikir az önce bahsettiğimiz gibidir:

“Bu mesajı daha önce işledim mi?”

Consumer bir mesajı aldığında, ilk olarak o mesajı benzersiz olarak tanımlayan kimlik bilgisi üzerinden bir kontrol sağlar. Bu kontrol, ilgili mesajın daha önce işlenip işlenmediğinin sorgulanmasıyla ilgilidir. İlgili mesaj daha önceden işlenmediyse işlenir ve o benzersiz kimliğe ait mesajın işlendiğine dair bir bilgi oluşturur. Bundan sonraki süreçte eğer aynı kimliğe sahip bir mesaj gelirse, o kimliğe sahip bir mesajın daha önce işlendiğini kayıtlardan anlayacak ve mesajı işlemeyecektir.

Burada mesaja benzersiz kimlik değerini de MessageId ile sağlıyoruz.

MessageId değeri, ilgili mesaja publish esnasında atadığımız değerdir. Bu değer benzersiz olacak şekilde belirlenir, dolayısıyla her bir mesaj benzersiz bir kimliğe sahiptir.

MessageId değerini şu şekilde oluşturup mesaja atayabiliriz:

...
var messageId = Guid.NewGuid().ToString();

var properties = new BasicProperties
{
    MessageId = messageId,
    ContentType = "application/json",
    Persistent = true
};

await channel.BasicPublishAsync(
    exchange: "",
    routingKey: "order-created",
    mandatory: true,
    basicProperties: properties,
    body: body
);

Bu şekilde artık publish ettiğimiz her bir mesaj bir kimliğe sahip oluyor.

3. İlk Idempotency Deneyi: ConcurrentDictionary ile Duplicate Kontrolü

Idempotency mantığını ilk olarak en basit haliyle görmek için, consumer tarafında işlenen MessageId değerlerini bir ConcurrentDictionary içerisinde tutabiliriz.

var processedMessages = new ConcurrentDictionary<string, byte>();

Artık işlenen mesajlarımızı burada tutacak, kontrollerimizi de buradan yapacağız. İsterseniz mesaj geldiğinde nasıl davranmamız gerektiğini de tanımlayalım:

consumer.ReceivedAsync += async (sender, args) => 
{ 
    var messageId = @event.BasicProperties?.MessageId;
    if (messageId == null)
    {
        Console.WriteLine("MessageId is null. Rejecting message.");
        await channel.BasicRejectAsync(@event.DeliveryTag, requeue: false);
        return;
    }
    
    if (!processedMessages.TryAdd(messageId, 0))
    {
        Console.WriteLine($"Message {messageId} has already been processed. Acknowledging message.");
        await channel.BasicAckAsync(@event.DeliveryTag, multiple: false);
        return;
    }
    
    Console.WriteLine($"Processing message {messageId}.");
    // ... process the message here ...

    await channel.BasicAckAsync(@event.DeliveryTag, multiple: false);
};

Bu tanımlama ile birlikte artık aynı MessageId değerine sahip mesajı iki kez publish ettiğimizde, ilk mesaj başarıyla işlenirken ikinci mesaj ignore’lanacaktır.

Bu ilk örneğimizde consumer’ımıza temel bir idempotentlik kattık ve genel mantığın nasıl işlediğini gördük. Uygulama içerisinde bir ConcurrentDictionary tutarak mesaj takibini sağladık.

Bu örnekte işlediğimiz mesajları memory’de sakladık. Dolayısıyla mesajlarımızın ömrü, uygulamanın ömrüyle eşdeğer oldu.

Dolayısıyla üstteki GIF’te olduğu gibi, uygulama her çöktüğünde processedMessages kayıtları siliniyor, uygulama her ayağa kalktığında da idempotentlik o anki mesajlar için sağlanmamış oluyor.

Buradan anlıyoruz ki mesajların geçici bir yerde saklanması, consumer’ların her zaman idempotent davranış göstermesi için ideal değil.

Bu sebeple bir diğer başlıkta, işlediğimiz mesajları Inbox Pattern ile birlikte kalıcı bir yerde tutacağız ve consumer’ların idempotent davranışını daha kalıcı hale getireceğiz.

4. Production’da Kalıcı Idempotency: ProcessedMessages ve Inbox Pattern

Consumer tarafında gelen ve işlenen mesajların kalıcı şekilde takip edilmesi için Inbox Pattern yaklaşımını kullanacağız.

Inbox Pattern’i kısaca şu şekilde açıklayabiliriz:

Consumer, işlediği mesajları kalıcı şekilde kaydeder ve aynı mesaj tekrar geldiğinde, bu kayıtları kullanarak ilgili kaydın daha önce işlenip işlenmediğini kontrol eder.

Biz de bu bölümde, Inbox Pattern’i oldukça sade bir şekilde kullanacak, Idempotent şekilde çalışmanın temeli olacak olan ProcessedMessages tablosunu oluşturacağız.

İşlediğimiz mesajları kalıcı olarak tutacağımızı söylemiştik. İsterseniz mesajlarımızı nasıl bir yapıda tutacağımızı ProccessedMessages tablosunu oluşturarak başlayalım.

public class ProcessedMessage
{  
   public string MessageId { get; set; } = null!; 
   public DateTime ProcessedAtUtc { get; set; }
}

Bu sınıfımız, veritabanında şöyle bir tabloya tekabül edecektir:

Burada MessageId alanının unique olarak tanımlanması oldukça önemlidir. Çünkü aynı mesaj farklı consumer instance’ları tarafından aynı anda işlenmeye çalışıldığında uygulama seviyesindeki kontrol yeterli olmayabilir. Bu sebeple hem uygulama tarafında, hem de veritabanı tarafında benzersizliği garanti ederek olası duplicate işlemi engellemeyi amaçlıyoruz.

Dipnot: Bu yazıda tek bir consumerdan söz ediyoruz. Eğer birbirinden farklı consumerlarımız varsa ve fanout exchange type’ını kullanıyorsak, ortak tablo kullanımında unique constraint tanımlamasını (MessageId,Consumer) olarak tanımlayabiliriz.

ProcessedMessages tablosunu işlediğimiz mesajların takibini yapmak ve duplicate mesajların işlenmesini engellemek adına oluşturduk.

İsterseniz şimdi de consumer’ın processedMessages tablo ile olan ilişkisinin nasıl olacağını, ne zaman tablo kontrolünün yapılması gerektiğini ve hangi anlarda bu tabloya kayıt eklenmesi gerektiğini kod seviyesinde tanımlayalım.

var messageId = @event.BasicProperties.MessageId;
 
var alreadyProcessed = await dbContext.ProcessedMessages
                       .AnyAsync(x => x.MessageId == messageId); 
if (alreadyProcessed) 
{ 
   Console.WriteLine($"Message {messageId} has already been processed."); 
   await channel.BasicAckAsync( @event.DeliveryTag, multiple: false); 
   return;
}

Consumer, mesajı ilk aldığında ilgili mesajı daha öncesinde işleyip işlemediğini kontrol etmesi gerekir. Bu kontrolün sonraki satırlara sarkması, gereksiz yere işlemlerin yapılmasına sebebiyet verebilir ve response’un daha geç oluşmasına sebep olabilir.

Eğer ilgili mesaj daha önce işlenmediyse, mesajı işlemeye devam edebiliriz.

Console.WriteLine($"Processing message {messageId}."); 

// Business işlemlerinin burada tamamlandığını farzedelim.
// Örneğin sipariş bildirimi oluşturma, stok güncelleme vb.
 
dbContext.ProcessedMessages.Add(
  new ProcessedMessage { 
    MessageId = messageId, 
    ProcessedAtUtc = DateTime.UtcNow }
  );
await dbContext.SaveChangesAsync(); 
await channel.BasicAckAsync( @event.DeliveryTag, multiple: false);

Mesajı başarıyla işlediğimiz senaryoda ProcessedMessages tablosuna mesajı işlediğimize dair kaydımızı yapıyoruz. Dolayısıyla aynı MessageId’ye sahip mesaj tekrardan consumer’a iletilirse ilgili kaydın varlığı sebebiyle mesaj işlenmeyecek ve idempotent davranışı sağlamış olacağız.

Bu noktada akışımızı şu şekilde görselleştirebiliriz:

Bu yaklaşımımız ile birlikte mesajlarımızın durumunu geçici tutmak yerine kalıcı hale getirdik ve idempotency’in kalıcı hale getirmiş olduk.

Tabii ki burada dikkat etmemiz gereken bir nokta var. Buradaki business process ile ProcessedMessages tablosuna kayıt ekleme işimiz birbiriyle doğrudan ilişkili olduğu aşikar.

İşlem başarılıysa kayıt eklenmeli, değilse eklenmemeli. Peki bu ilişki kod seviyesinde de garanti edildi mi?

5. Business Operation ile Inbox Kaydı Neden Aynı Transaction’da Olmalı?

Bir önceki bölümde consumer’ın işlediği mesajları ProcessedMessages tablosunda saklayarak kalıcı bir idempotency mekanizması oluşturduk.

Fakat burada dikkat etmemiz gereken önemli bir nokta var:

Business operation başarılı olurken ProcessedMessages kaydı oluşturulamazsa ne olur?

İsterseniz bunu basit bir senaryo üzerinden düşünelim.

Consumer bir OrderCreated mesajı aldı ve siparişe ait ürünün stok miktarını 1 azalttı. Yani business operation başarıyla tamamlandı. Fakat hemen sonrasında uygulamanın çöktüğünü ve mesajın işlendiğine dair ProcessedMessages kaydının veritabanına yazılamadığını düşünelim.

Aynı zamanda consumer RabbitMQ’ya ACK gönderemediği için broker, mesajın başarıyla işlendiğinden emin olamaz ve aynı mesajı tekrar consumer’a iletebilir.

Consumer mesajı ikinci kez aldığında ProcessedMessages tablosunu kontrol eder. Ancak önceki işlemde herhangi bir kayıt oluşturulamadığı için ilgili MessageId değerini bulamaz ve mesajı daha önce hiç işlememiş gibi tekrar işler.

Sonuç olarak aynı OrderCreated mesajı iki kez business etkisi oluşturmuş olur:

İlk teslimat  → Stok -1
İkinci teslimat → Stok -1

Günün sonunda tek bir sipariş için stok miktarı iki kez azaltılmış olur.

İşte tam olarak bu yüzden, business operation ile mesajın işlendiğine dair Inbox kaydının birbirinden bağımsız işlemler olarak ele alınmaması gerekir.

await using var transaction =
    await dbContext.Database.BeginTransactionAsync();

try
{
    var alreadyProcessed = await dbContext.ProcessedMessages
        .AnyAsync(x => x.MessageId == messageId);

    if (alreadyProcessed)
    {
        await transaction.RollbackAsync();
        await channel.BasicAckAsync(args.DeliveryTag, false);
        return;
    }

    // Business operation
    product.Stock--;

    // Inbox kaydı
    dbContext.ProcessedMessages.Add(new ProcessedMessage
    {
        MessageId = messageId,
        ProcessedAtUtc = DateTime.UtcNow
    });

    await dbContext.SaveChangesAsync();
    await transaction.CommitAsync();

    // Commit'ten sonra ACK
    await channel.BasicAckAsync(args.DeliveryTag, false);
}
catch
{
    await transaction.RollbackAsync();

    await channel.BasicNackAsync(
        args.DeliveryTag,
        multiple: false,
        requeue: true);
}

Bu sebeple birbiriyle doğrudan ilişkili olan bu iki işlemi ortak transaction ile atomik hale getirebiliriz.

6. ACK Neden Database Commit’ten Sonra Gönderilmeli?

await dbContext.SaveChangesAsync();
await transaction.CommitAsync();

// Commit'ten sonra ACK
await channel.BasicAckAsync(args.DeliveryTag, false);

Burada ACK bildirisinin commit’ten sonra olması oldukça önemlidir. Bunun sebebi ACK bildirisinin yapılması ile veritabanı değişikliklerinin uygulanmasının birbirinden farklı şeyler olmasıdır. Eğer biz commit öncesinde ACK bildirisi yaparsak ve herhangi bir commit hatası alırsak, yaptığımız business işlemler geçersiz olacak ve ACK göndereceğimiz için mesaj queue’dan silinecektir.

Bu kısımda da tek bir satır konumunun, tutarlılığı nasıl etkileyebileceğini görmüş olduk.

7. Producer Tarafındaki Problem: Dual Write

Yazımızın bu noktasına kadar güvenilir mesajlaşmayı sağlamak adına odağımız consumer tarafındaydı. Fakat güvenilir mesajlaşmada producer tarafında da önemli bir problemimiz var.

Bu problem, Dual Write.

Bir sipariş oluşturduğumuzu düşünelim. Uygulamamız ilk önce sipariş bilgisini veritabanına kaydediyor, ardından da OrderCreated mesajını RabbitMQ’ya publish ediyor. Akışımız şu şekilde olsun:

İlk bakışta bir problem yokmuş gibi gözüküyor. Kod satırlarının ne ile ilgili olduğuna baktığımızda şunu çıkarıyoruz:

Göreceğimiz üzere kod parçası hem database, hem de RabbitMQ ile ilgili işlemler yapıyor ve bu işlemler sıralı şekilde tanımlanmış.

Peki bu sıralı işlemler ya yarıda kalırsa ne olacak? Yine bir tutarsızlık söz konusu.

Hatırlarsanız şuanda yaşadığımız problemin bir benzerini consumer tarafında yaşamış ve bunu inbox pattern ile çözmüştük. Gerçekleştirdiğimiz business işlem ile processedMessages tablosuna yapacağımız işlemleri tek bir transaction içerisine alıp reliability’i sağlamıştık.

Çözümümüz şu şekildeydi: İki işlem, tek transaction.

Peki consumer tarafında ne yapabiliriz? Inbox Pattern’indeki çözüm şekli, bize yardımcı olabilir mi?

8. Outbox Pattern Nedir ve Dual Write Problemini Nasıl Çözer?

Consumer tarafında uyguladığımız Inbox Pattern’de iki farklı işlemi aynı transaction içerisine alarak tutarlılığı sağlamıştık. Producer tarafında da benzer bir yaklaşım uygulayabiliriz.

Buradaki temel fikir şu:

Business verisini ve publish edilmesi gereken mesajı aynı database transaction içerisinde kaydetmek.

Yani siparişi oluşturduğumuz anda mesajı doğrudan RabbitMQ’ya publish etmek yerine, önce bu mesajı veritabanındaki bir OutboxMessages tablosuna kaydederiz.

await using var transaction = await dbContext.Database.BeginTransactionAsync();

dbContext.Orders.Add(order);
dbContext.OutboxMessages.Add(new OutboxMessage
{
    Id = Guid.NewGuid(),
    Type = "OrderCreated",
    Payload = JsonSerializer.Serialize(orderCreatedEvent),
    CreatedAtUtc = DateTime.UtcNow
});

await dbContext.SaveChangesAsync();
await transaction.CommitAsync();

Bu durumda iki işlem de aynı transaction içerisinde gerçekleşir:

Transaction başarılı olursa hem sipariş hem de ona ait mesaj kaydedilmiş olur. Herhangi bir hata yaşanırsa ise ikisi de rollback edilir.

Böylece artık “Order kaydedildi ama OrderCreated mesajı kayboldu.” gibi bir durumun yaşanması önlenmiş olur.

Peki mesaj RabbitMQ’ya nasıl ulaşacak?

Burada devreye ayrı bir Outbox Publisher girer. Bu yapı belirli aralıklarla henüz publish edilmemiş OutboxMessages kayıtlarını okur ve RabbitMQ’ya gönderir.

Mesaj broker tarafından güvenli şekilde kabul edildiğinde ise ilgili Outbox kaydı publish edilmiş olarak işaretlenir.

Bu yaklaşım sayesinde database ile RabbitMQ arasında doğrudan tek bir transaction kurmaya çalışmak yerine, önce güvenilir olan database transaction’ından faydalanmış oluruz.

İşte bu yaklaşım Outbox Pattern olarak adlandırılır.

Kısacası:

Inbox, consumer tarafında mesajın birden fazla kez işlenmesini engellerken; Outbox, producer tarafında business işlem ile mesaj üretimi arasındaki tutarlılığı korur.

9. Outbox Publisher, MessageId ve PublishedAtUtc

Outbox tablosuna kaydettiğimiz mesajların RabbitMQ’ya iletilmesi için bir Outbox Publisher kullanırız. Bu yapı belirli aralıklarla henüz publish edilmemiş kayıtları bulur ve broker’a gönderir.

var messages = await dbContext.OutboxMessages
    .Where(x => x.PublishedAtUtc == null)
    .ToListAsync();

Her Outbox kaydının benzersiz Id değerini, RabbitMQ mesajının MessageId değeri olarak kullanabiliriz:

properties.MessageId = outboxMessage.Id.ToString();

Böylece aynı Outbox mesajı tekrar publish edilmek zorunda kalırsa yeni bir MessageId üretmek yerine aynı kimliği koruruz. Böylece olası duplicate message senaryosunda messageId aynı kalacağı için consumer’ın idempotent şekilde davranmasını sağlayabiliriz.

Gönderdiğimiz mesaj broker tarafından başarıyla kabul edildiğinde ilgili kayıt işaretlenir:

outboxMessage.PublishedAtUtc = DateTime.UtcNow;
await dbContext.SaveChangesAsync();

PublishedAtUtc, bize bu Outbox kaydının artık publish sürecinden geçtiğini gösterir. Böylece publisher sonraki taramalarda yalnızca henüz publish edilmemiş kayıtlarla ilgilenir.

10. Outbox Duplicate Publish’i Tamamen Engeller mi?

Outbox Pattern’in ana amacı duplicate publish’i engellemek değil, olası mesaj kayıplarını engellemektir. Dolayısıyla duplicate publish’in engellenmesi hususunda rol oynamaz.

Şu senaryoyu düşünelim:

Mesaj RabbitMQ'ya ulaştı
        ↓
Broker ACK gönderdi
        ↓
Publisher ACK'i alamadan bağlantı koptu
        ↓
PublishedAtUtc güncellenemedi

Outbox kaydı hala publish edilmemiş gibi göründüğü için Outbox Publisher daha sonra aynı mesajı tekrar gönderebilir.

Sonuç olarak aynı MessageId değerine sahip mesaj broker’a birden fazla kez ulaşabilir.

Bu aslında daha önce de bahsettiğimiz durumun aynısıdır: at-least-once delivery duplicate mesaj üretebilir.

Dolayısıyla Outbox Pattern ile Inbox Pattern birbirinin tamamlayıcısıdır:

Outbox mesajın kaybolmamasını sağlar, Inbox ise aynı mesajın birden fazla kez işlenmesinin etkisini engeller.

Böylece producer ve consumer tarafını birlikte ele aldığımızda daha güvenilir bir mesajlaşma yapısı elde etmiş oluruz.

11. Outbox ve Inbox Birlikte Nasıl Çalışır?

Outbox ve Inbox Pattern aslında birbirini tamamlayan iki yapıdır.

Outbox Pattern, producer tarafında mesajların kaybolmasını engeller. Business işlem ile publish edilmesi gereken mesaj aynı transaction içerisinde saklanır ve mesaj, broker’a başarıyla iletilene kadar tekrar gönderilebilir.

Bu yaklaşım bize at-least-once delivery garantisi sağlar. Ancak bu garanti beraberinde duplicate message riskini de getirir.

İşte bu noktada Inbox Pattern devreye girer. Consumer, daha önce işlediği mesajları MessageId üzerinden takip ederek aynı mesaj tekrar ulaştığında business işlemi yeniden gerçekleştirmez.

Bu iki pattern birlikte kullanıldığında, producer ve consumer tarafında daha güvenilir ve tutarlı bir mesajlaşma akışı elde edilir.

12. Part 3’e Geçiş: Consumer Mesajı İşleyemezse Ne Olacak?

RabbitMQ Reliability serisinin ilk bölümünde, publisher tarafından iletilen mesajların broker’a sağlıklı şekilde iletilmesini hakkında konuştuk.

Bu bölümde ise broker’a güvenli şekilde iletilen mesajların sahip olduğu olası duplicate durumlarını consumer tarafında nasıl yönetebileceğimizi imceledik. İşlenen her bir mesajın durumunu kayıt altına alarak consumer’larımızın idempotent şekilde çalışmasını sağladık. Publisher tarafında da oluşturulan event’ların kaybolmamasını Outbox Pattern ile sağlamış olduk.

Bu serinin son bölümü olacak Part-3'te ise , consumer’larımızın mesajları işleyemedikleri durumlarda nasıl davranması gerektiği ile ilgili olan Retry,DLQ, Backoff ve Jitter kavramlarından bahsederek bu seriyi sonlandıracağım.

Yazılarımda henüz yeni öğrendiğim şeylerden bahsediyorum. Dolayısıyla yanlış öğrendiğim/bahsettiğim yerler olabilir, mazur görünüz.

İyi okumalar dilerim.

RabbitMQ Reliability — Part 2: Duplicate Messages, Idempotency, Inbox & Outbox was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

RabbitMQ Güvenilirliği — Bölüm 1

Bir mesajın broker’a gerçekten ulaşıp ulaşmadığını nasıl anlayabilir, bağlantı kopmalarında mesaj kaybını nasıl azaltabiliriz?

Merhaba, bu yazıda message broker kullandığımız sistemlerde asenkron iletişimi nasıl daha güvenilir hale getirebileceğimizden bahsedeceğim.

Özellikle bir mesajı publish ettiğimizde, bu mesajın gerçekten broker tarafından alınıp alınmadığını nasıl anlayabileceğimizi ve olası bağlantı problemlerinde mesaj kaybını nasıl önleyebileceğimizi inceleyeceğiz.

1. Bir Mesajı Publish Etmek Gerçekten Yeterli mi?

RabbitMQ ile çalışmaya ilk başladığımızda akış oldukça basit görünür. Publisher kendi içerisinde yapması gereken işlemi yapar, ardından yaptığı işlem ile ilgili bir mesaj publish eder. Publish edilen mesaj broker’a ulaşır ve ilgili consumerlar bu mesajları tüketir.

Peki ilk başladığımızda bu kadar basit görünen şey, neden karmaşıklaşır?

Bu sorunun cevabını doğrudan vermek yerine, bir sistem kurgulayıp o kurgu üzerine düşünürken bulalım istiyorum. Bu sebeple şu örnek ile devam edelim.

Bir e-ticaret platformunda sipariş oluşturuldukça, ilgili siparişleri oluşturan müşterilere siparişlerinin başarıyla oluşturulduğuna dair bildirim gönderilir. Biz de bu yapıyı basitçe tasarlayalım, sonrasında başımıza gelebilecek problemleri deneyimleyip bu problemleri çözmek adına neler yapabileceğimize bakalım.

Kurguladığımız yapı şuanda bu şekilde. İsterseniz direkt bir mesaj publish ederek akışın nasıl olduğuna bakalım.

İlgili kod ile event’ımızı broker’a publish ettik. Alttaki görselde de mesajın başarıyla broker’a iletildiğini görebiliriz.

Şuanda istediğimiz şeyi kolaylıkla yapabildik çünkü her şey istediğimiz gibiydi. Peki her şey her zaman istediğimiz gibi olabilir mi?

Message broker’lar çoğu zaman bir sunucuda çalışır ve ağ üzerinden iletişime geçilebilir haldedirler. Dolayısıyla hem producer, hem de consumer’lar ağ üzerinden broker’a yazabilir ve tüketebilir. Az önceki senaryomuzda ağ gayet sağlıklıydı ve biz istediğimizi yapabildik. İsterseniz şimdi de broker’ın çalışmayı durdurduğu senaryoda neler olacağını gözlemleyelim. Çünkü gerçek hayatta her şey istediğimiz gibi olmayabilir.

Kodumuzu şu şekilde güncelledim:

Uygulama mesajı publish etmeden önce broker process’ini durduracağım ve mesajı publish edeceğim. Mesaj publish ettikten sonra da broker’ı tamamen kapatacağım. Bakalım mesajımız gerçekten broker tarafından alınacak mı?

Eklediğim GIF’te gördüğünüz üzere producer tarafı mesajı başarıyla publish ettiğini söylerken broker tarafında bu mesaj yok.

Tabiri caizse publisher ile broker arasında şöyle bir muhabbet var:

Biz producer olarak mesajı publish ettik ama broker mesajımızı alamadı. Dolayısıyla mesaj da kayboldu.

Peki biz burada nasıl bir yapı olmasını isterdik?

Broker keşke mesajı başarıyla alıp almadığının bilgisini bize verseydi, biz de ona göre mesajımızı tekrardan publish eder yada silerdik.

2. Publisher Confirms

Publisher confirms, publisher tarafından broker’a iletilen mesajların broker tarafından başarılı şekilde alınıp alınmadığı bilgisinin producer’a iletilmesini sağlar. Broker, publisher confirm özelinde ACK ve NACK olmak üzere 2 tür bilgilendirmeyi publisher’a iletir.

ACK, mesajın broker tarafından başarıyla kabul edildiğini doğrularken; NACK, broker’ın mesaj için olumlu bir publisher confirm veremediğini ifade eder.

Böylece publisher ilettiği mesajların durumunu takip edebilir ve gerekli aksiyonları alabilir.

Bu yapı, default olarak kapalı geliyor. Dolayısıyla publisher-broker arasındaki etkileşim varsayılan olarak şu şekilde:

Publisher confirm kapalı olduğunda broker tarafından mesajın sağlıklı şekilde alınıp alınmadığı ile ilgili bilgi gönderilmiyor. Dolayısıyla publisher tarafı ilettiği mesajın sağlıklı şekilde alınıp alınmadığı ile ilgili bilgiye sahip değil.

Bu yapıyı açmak için channel oluşturma sırasında ilgili konfigürasyonu channel’a tanımlamak gerekiyor.

Bu tanımlamayı şu şekilde yapabiliriz:

Görseldeki kod ile birlikte gerekli tanımlamayı yaptığımızda ise publisher-broker arasındaki etkileşim şu hale geliyor:

Görüldüğü üzere publisher confirm edilmesiyle birlikte publisher gönderdiği mesajın durumu ile ilgili bilgiye sahip oluyor. Herhangi bir mesaj o anda nack alırsa o mesajı tekrardan publish edebilmesi için ilgili bilgilendirmeyi alabiliyoruz artık.

Dikkat ederseniz ACK durumunda gönderdiğimiz ‘order-created’ mesajını queue içerisine yazmadım. Bu şekilde yapmamın özel bir sebebi var. ACK, ilgili mesaj broker tarafından başarılı şekilde alındığında yayınlanır. Mesajın herhangi bir queue’ya yönlendirilip yönderilmemesiyle ilgili değildir. Dolayısıyla herhangi bir mesaj broker’a sağlıklı şekilde iletilse bile bir queue’ya yönlendirilemeyebilir. Bizler tabii ki burada yönlendirilemeyen mesajların kaybolmasını istemeyiz. Buna yazının devamında değineceğim.

Bu noktaya kadar gönderdiğimiz mesajların durumuyla akalı bilgi alabilir hale geldik. Peki biz bu bilgileri nasıl alıyoruz ve bu bilgiler ışığında nasıl aksiyon alabiliriz?

İlk olarak ACK ve NACK bildirimlerinin publisher tarafında nasıl değerlendirileceğinden bahsedeceğim.

Broker tarafı, kendisine gönderilen mesajı başarılı şekilde işlediğinde ACK gönderdiğinden bahsetmiştik. Bu ACK bildirisi, publisher tarafında BasicAcksAsync() metodunu tetikliyor. Biz de bu sayede publisher tarafında ilgili mesajın onaylanması halinde yapacağımız işlemleri yapabiliyoruz.

Alttaki GIF ile akışı göstermeye çalıştım.

Aynı şey NACK için de geçerli. İlgili mesaj broker tarafından başarıyla işlenemediği durumda NACK bildirisi publisher tarafında BasicNacksAsync() metodunu tetikliyor. Aynı şeyler bu metod için de geçerli.

Bu kısma kadar ACK ve NACK bildirilerinin nasıl ele alınacağından bahsetmiş oldum. Şimdi bahsetmek istediğim konu ise biraz önce değindiğim ‘broker tarafından başarıyla alınan fakat herhangi bir queue’ya route edilemeyen’ mesajlar ile ilgili.

Mesajları publisherdan farklı şekillerde gönderebiliyoruz. Bu şekiller amacımıza göre değişeceğinden mesajlar kimi zaman kesinlikle bir queue’ya route edilmesi gerekirken kimi zamanda route edilmesi şart değildir. Publisher tarafından gönderilen mesajın kesinlikle bir queue’ya route edilmesini istiyorsak mesajı gönderirken “mandatory:true” tanımlamasını yapmamız gerekir.

await channel.BasicPublishAsync(
    exchange: string.Empty, 
    routingKey: "order-created.queue", 
    mandatory: true, 
    body: eventBody);

Bu tanımlama ile birlikte ilgili mesaj herhangi bir queue’ya yönlendirilemediğinde publisher tarafında BasicReturnAsync() metodunu tetikleyecektir.

Unroutable mesajları publisher confirm’den ayrı şekilde değerlendirmemiz gerekir. Çünkü unroutable mesajlar broker tarafından başarıyla işlenmiş mesajlardır. Dolayısıyla “mesajım broker tarafından ACK aldı, bu yüzden brokerda illaki bir queue’ya yönlendirilmiştir” gibi bir yanılgıya düşmemeliyiz.

3. Publisher Confirmation Tracking

Buraya kadar publisher confirm mekanizmasının ACK ve NACK bildirimleri üzerinden nasıl çalıştığını gördük. Bu noktada kendimize şu soruyu sorabiliriz:

Broker’dan gelen ACK veya NACK bilgisinin hangi publish işlemimize ait olduğunu nasıl takip edeceğiz?

Bu gayet mantıklı bir soru. İncelediğimiz örneklerde birer mesaj üzerinden gösterim yaptık. Ya binlerce mesaj publish edeceksek bunların takibini nasıl yapacağız?

RabbitMQ .NET Client bu noktada bize publisherConfirmationTrackingEnabled adında bir özellik sunuyor.

Channel oluştururken bu özelliği şu şekilde aktif edebiliriz:

Burada publisherConfirmationsEnabled ile Publisher Confirms mekanizmasını aktif ederken, publisherConfirmationTrackingEnabled ile RabbitMQ Client’ın confirmation işlemlerini bizim yerimize takip etmesini sağlıyoruz.

Peki tracking özelliğini true yaptığımızda tam olarak ne oluyor?

Tracking aktif olduğunda RabbitMQ .NET Client, publish ettiğimiz mesaj ile broker’dan gelen confirmation bilgisini kendi içerisinde eşleştiriyor. Böylece BasicPublishAsync() metodunu await ettiğimizde publish işleminin sonucunu doğrudan ilgili task üzerinden takip edebiliyoruz.

Örneğin:

try
{
    await channel.BasicPublishAsync(
        exchange: string.Empty,
        routingKey: "order-created.queue",
        mandatory: true,
        body: eventBody);

        Console.WriteLine("Message successfully confirmed.");
}
catch (Exception ex)
{
    Console.WriteLine($"Publish failed: {ex.Message}");
}

Bu yapıda mesaj ACK aldığında BasicPublishAsync() başarılı şekilde tamamlanır.

Mesaj NACK aldığında veya mandatory : true olduğu halde herhangi bir queue’ya route edilemediğinde ise publish işlemi exception ile sonuçlanır. Dolayısıyla tracking açıkken confirmation sürecinin önemli bir kısmını RabbitMQ Client bizim yerimize yönetiyor.

Client bunu nasıl yönetiyor diye düşünüyor olabiliriz. Tam da şu şekilde yönetiyor :

RabbitMQ.Client gönderdiği her bir mesaj için ilgili channel içerisinde lineer artan bir değişken tutar. Bu değişken değeri her iletilen mesaj ile birlikte birer birer artar. Publisher tarafında ilettiği her bir mesajın sequental number değerini kendi içerisinde saklar ve mesajı publish eder. Brokerdan dönen ACK/NACK bildirisinin argümanlarında ‘DeliveryTag’ değeri bulunur. Bu deliveryTag değeri de aslında mesaja atadığı sequental number’ın kendisidir. Bu değere göre gönderdiği mesajlardan hangisinin başarılı yada başarısız şekilde iletildiğini takip edebilir.

Bu oldukça kullanışlıdır. Çünkü gönderdiğimiz her mesaj için sequence number üretmek, pending mesajları saklamak ve ACK/NACK geldiğinde ilgili mesajı manuel olarak bulmak zorunda kalmayız.

Ancak bu kolaylığın karşılığında bazı kontrolleri de client’a bırakmış oluruz.

Örneğin tracking açıkken confirmation mekanizmasının iç detaylarına uygulama seviyesinde erişimimiz oldukça kısıtlanıyor.

Örneğin:

• Hangi mesajlar ACK aldı?
• Hangi mesajlar hala pending durumda?
• Connection koptuğu anda hangi mesajların durumu artık kesin olarak bilinemeyecek?
• Recovery sonrasında hangi mesajları tekrardan publish etmeliyiz?

İşte bu gibi sorulara cevap bulabilmek için publisher confirm’u kendimiz yönetmeliyiz. Kontrol elimizde olduğunda bu soruların cevaplarını kolaylıkla verebiliyor olacağız.

İsterseniz kontrolü elimize alarak devam edelim.

“publisherConfirmationTrackingEnabled : false” dediğimizde tracking’i rabbitMQ.Client üzerinden alıyor ve kendimizin yöneteceğini dikte ediyoruz.

Biraz önce RabbitMQ.Client’ın sequenceNumber’lar vesilesiyle ACK/NACK yönetimini nasıl yaptığından bahsetmiştim. Aynı mantığı kendimiz uygulayacağız. Gönderdiğimiz mesajların takibini yapabilmek için ConcurrentDictionary oluşturacağız. Mesajlarımızı publish etmeden önce bu dictionary’e atacağız ve brokerdan gelen ACK/NACK bilgisine göre dictionary’i güncelleyeceğiz. Böylece herhangi bir connection failure durumunda mesajların state’leri hakkında bilgiye sahip olacağız.

var pendingMessages = new ConcurrentDictionary<ulong, string>();

Göndereceğimiz mesajların takibini yapabilmek için bir dictionary oluşturduk.

Göndermek istediğimiz mesaj şu şekilde olsun.

var message = new OrderCreatedEvent
{
    Id = Guid.NewGuid(),
    OrderId = Guid.NewGuid(),
    CreatedTime = DateTime.UtcNow
};

Şimdi ise, göndereceğimiz mesajın takibini yapabilmek için ilgili mesaja atanacak olan sequenceNumber bilgisini alalım.

var sequenceNumber = await channel.GetNextPublishSequenceNumberAsync();

SequenceNumber bilgisini de aldık. Artık broker’a göndereceğimiz mesajın takibini yapabilmek için herşeye sahibiz. O zaman göndereceğimiz mesajın kaydını dictionary’e yapalım ve mesajımızı publish edelim.

pendingMessages.TryAdd(
    sequenceNumber,
    JsonSerializer.Serialize(message));

await channel.BasicPublishAsync(
    exchange: "",
    routingKey: "order-created",
    body: Encoding.UTF8.GetBytes(JsonSerializer.Serialize(message)));

Mesajlarımızı yayınladığımızda pendingMessages şu şekilde olacak:

Bu noktada broker’a göndereceğimiz mesajları bir dictionary aracılığı ile takip ediyoruz. Peki ACK/NACK olduğunda pendingMessages nasıl güncellenmeli?

Sizin de tahmin edeceğiniz üzere daha önce bahsettiğimiz BasicAcksAsync/BasicNacksAsync metodları ile yapacağız:

Bu metodumuz ile birlikte broker mesajı sağlıklı şekilde aldığında ilgili mesajı pendingMessages’tan çıkarıyoruz. Dolayısıyla broker tarafında oluşabilecek herhangi bir fail anında broker’a tekrardan publish edilmesi gereken mesajlar pendingMessages içerisinde bekliyor olacak. Başarıyla iletilen mesajlar pendingMessages içerisinde bulunmayacağı için aynı mesajı tekrar tekrar göndermemiş olacağız. Burada kısmi idempotentlik sağlıyoruz diyebiliriz. Çünkü ilettiğimiz mesajı tekrardan göndermiyoruz. Tabii ki asıl idempotentlik davranışını consumer tarafında kazandıracağız. Buna da bu yazının diğer partlarında değineceğim.

4. Connection Failure ve Unknown Mesajlar

Yazımızın bu noktasına kadar broker’a gönderilen mesajların broker tarafından sağlıklı şekilde alınıp alınmamasıyla ilgili konuştuk.

Peki şunu düşündük mü :

Publish ettiğim mesaj ya broker’a dahi ulaşamadıysa ne olacak? Yada broker’a ulaşan bir mesajdan ACK dönerken connection düşerse ne yapacağız?

Broker ile olan bağlantımız herhangi bir anda koparsa ve biz o anda mesajlarımızı publish ediyorsak, mesajlarımızın broker’a başarılı ulaşıp ulaşmadığı ile ilgili kesin bir bilgi sahibi olamayız. Çünkü mesajımız henüz broker’a ulaşmadan bağlantı kopmuş olabilir. Yada mesajımız broker’a başarılı şekilde ulaşmış ve publisher’a ACK bildirisi yayınlanmışken bağlantı kopmuş olabilir.

Aklımızda canlandırmak amacıyla alttaki görseli inceleyebiliriz:

Üstteki görselde , broker tarafından alınan mesajın connection failure olması sebebiyle ACK bildirisini iletememesini, dolayısıyla ilgili mesajın hala pending durumunda olmasını ifade etmeye çalıştım.

Peki biz ne yapacağız?

Connection failure durumlarında ‘mesajımı gönderdim ve broker’dan confirm bekliyorum’ gibi senaryolarda pendingMessages’ta bulunan mesajları unknown olarak işaretlemeliyiz. Çünkü bu mesajların en az 1 kere iletilip iletilmediği garanti edilmediği için tekrardan publish edilmesi gerekir.

Unknown olarak işaretlediğimiz mesajları, connection recovery olduğunda tekrardan publish ederek mutlaka 1 kez broker’a pushlanmasını garanti etmeye çalışacağız ( at least one delivery ).

İsterseniz bu yapıyı da koda dökelim.

public enum PublishState
{
    Pending,
    Unknown
}

Artık pendingMessages’ta sadece ‘Pending’ durumundaki mesajları değil, aynı zamanda ‘Unknown’ olan mesajları tutacağız. bu sebeple bir enum ile bunu ifade edelim.

class PendingPublish { 
  public required string Body { get; init; } 
  public PublishState State { get; set; } 
}

PendingMessages’ta artık sadece mesajın body’sini değil, aynı zamanda state’ini de tutacağız.

var pendingMessages = new ConcurrentDictionary<ulong, PendingPublish>();

Dictionary’in value değerini artık PendingPublish olarak tutacağız. Mesajların republish edilme işlemini de bu State değerine göre yapacağız.

pendingMessages.TryAdd( sequenceNumber, new PendingPublish { 
  Body = JsonSerializer.Serialize(message), 
  State = PublishState.Pending });

Mesajları publish etmeden önce dictionaryde tutuyorduk. Artık PendingPublish tutacağımız için pendingMessage’a kayıt ekleme işlemini de bu şekilde güncelleyelim.

Publisher olarak mesajlarımızı artık state’leri ile birlikte tutuyoruz. Bağlantı koptuğunda mesajlarımızın state’ini ‘unknown’ olarak işaretleyeceğimizden bahsetmiştik.

Peki bunu nasıl yapacağız?

connection.ConnectionShutdownAsync() metoduyla.

connection.ConnectionShutdownAsync += async (_, args) =>
{
    Console.WriteLine();
    Console.WriteLine("========== CONNECTION SHUTDOWN ==========");
    Console.WriteLine($"ReplyCode : {args.ReplyCode}");
    Console.WriteLine($"ReplyText : {args.ReplyText}");
    Console.WriteLine($"Initiator : {args.Initiator}");
    Console.WriteLine($"Cause     : {args.Cause?.Message}");

    var unknownCount = 0;

    foreach (var item in pendingMessages)
    {
        if (item.Value.State != PublishState.Pending)
            continue;

        item.Value.State = PublishState.Unknown;
        unknownCount++;

        Console.WriteLine(
            $"[UNKNOWN] Seq={item.Key} | MessageId={item.Value.MessageId}");
    }

    Console.WriteLine(
        $"[CONNECTION LOST] {unknownCount} pending message marked as UNKNOWN.");

    Console.WriteLine("=========================================");
    Console.WriteLine();

    await Task.CompletedTask;
};

.ConnectionShutdownAsync() metodu da , çeşitli davranışlar ile tetikleniyor. Tıpkı ACK-NACK bildirimi gibi. Broker ile olan bağlantımız koptuğunda tetiklenen bu metod ile birlikte mesajlarımızın state’ini unknown olarak işaretleyeceğiz. Böylece recovery durumunda mesajlarımızı tekrardan gönderebilelim.

Buraya kadar çoğu adımımızı tanımladık. Mesajlarımızı gönderdik, confirm bekledik, herhangi bir connection fail durumunda da mesajlarımızın durumunu güncelleyerek tekrardan iletebilir hale geldik.

Peki bu mesajları ne zaman tekrardan iletebileceğiz diye sorarsak ta o anda bize ‘connection.RecoverySucceededAsync() yardımcı olacak.

Not: ConnectionFactory oluşturulurken “AutomaticRecoveryEnabled = true” değeri default olarak true’dur. Bu sebeple recovery olduğunda ilk olarak channel’lar tekrardan oluşturulur. İlgili RecoverySucceededAsync() metodu bu aşamadan sonra çalışır durumda olacaktır.

connection.RecoverySucceededAsync += async (sender, args) =>
{
    var unknownMessages = pendingMessages
        .Where(x => x.Value.State == PublishState.Unknown)
        .ToList();

    foreach (var item in unknownMessages)
    {
        var oldSequenceNumber = item.Key;
        var message = item.Value;

        pendingMessages.TryRemove(
            oldSequenceNumber,
            out _);

        var newSequenceNumber =
            await channel.GetNextPublishSequenceNumberAsync();

        message.State = PublishState.Pending;

        pendingMessages.TryAdd(
            newSequenceNumber,
            message);

        try
        {
            await channel.BasicPublishAsync(
                exchange: string.Empty,
                routingKey: "order-created",
                mandatory: true,
                body: Encoding.UTF8.GetBytes(message.Body));

            Console.WriteLine(
                $"[REPUBLISH] OldSeq={oldSequenceNumber} | " +
                $"NewSeq={newSequenceNumber}");
        }
        catch (Exception ex)
        {
            message.State = PublishState.Unknown;

            Console.WriteLine(
                $"[REPUBLISH FAILED] Seq={newSequenceNumber} | " +
                $"Error={ex.Message}");
        }
    }
};

Metodu bu şekilde tanımlayabiliriz. Dikkat ederseniz unknown durumundaki mesajların state’i pending olarak değiştirilip publish edilmiyor. Bunun sebebi sequence number’ların channel bazlı tanımlanmasıdır. Örneğin bir channel açıldı ve sequence numaralar 1 den başlayarak dağıtılmaya başlandı. Eğer connection koparsa ilgili channel de kapanır. Dolayısıyla ilgili sequence numberlar da eski bir channeldaki tanımlanan referansı gösterir. Buradaki sequence number’ı güncellemek oldukça önemlidir. Buradaki sequence number’ı güncellemezsek 2 farklı mesaj birbirlerini istemeden ACK edilmesine sebebiyet verebilir.

İsterseniz connection fail durumunda mesajlarımızın unkown olarak işaretlenmesini, ardından yaşanacak recovery ile birlikte de unknown mesajların republish edilmesini simüle edelim.

Broker’ı tekrardan ayağa kaldırdığımızda ne olacak? Hadi bakalım.

Broker tekrardan aktif olduğunda mesajlarımız tekrardan publish edilmiş oldu.

Bu yazımda Publisher Confirms, ACK/NACK, mandatory:true, confirmation tracking ve connection failure durumlarında mesajların nasıl takip edilebileceği ve recovery sürecinde neler yapabileceğimiz ile ilgili öğrendiklerimden bahsetmek istedim.

Bu yazının devamı niteliğinde olacak Part 2’de ise, recovery sürecinin beraberinde getirebileceği Duplicate Message problemine odaklanacağız. Aynı mesajın consumer tarafında birden fazla kez işlenmesinin ne gibi sorunlara yol açabileceğini ve bu problemleri nasıl önleyebileceğimizi inceleyeceğiz.

Yazılarımda henüz yeni öğrendiğim şeylerden bahsediyorum. Dolayısıyla yanlış öğrendiğim/bahsettiğim yerler olabilir, mazur görünüz.

İyi okumalar dilerim.

RabbitMQ Reliability — Part 1: Publisher Confirms, Connection Failure & Recovery was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

Birlikte Değişen Kodlar, Birlikte Yaşamalı

TkDodo ve Dan Abramov gibi isimlerin sıkça vurguladığı temel bir kural vardır: Birlikte değişen kodlar, birlikte yaşamalıdır. Birçok projede ile hook’ları aynı klasörde dururken, ile bileşeni ayrı yerlerde bulunur. Bu durum küçük projelerde sorun yaratmasa da, proje büyüdükçe kodun takibini zorlaştırır ve ölçeklenebilirliği düşürür.

Feature-driven yaklaşım, uygulamanın her bir özelliğini kendi içinde bağımsız birer mini-uygulama gibi tasarlar.

src/
├── features/
│   ├── auth/
│   │   ├── api/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── schemas/
│   │   └── index.ts
│   └── dashboard/
├── components/
│   └── shared/
└── lib/

Bu yapı sayesinde, projenin klasörlerine baktığınızda uygulamanın sadece React ile yazıldığını değil, ne işe yaradığını doğrudan anlarsınız.

Sınırlar ve Public API

Bu mimarinin en güçlü yanı sınırları net çizmesidir. Her feature klasöründeki dosyası, o özelliğin dışarıya açılan kapısıdır (Public API).

// src/features/auth/index.ts
// Sadece dışarıdan erişilmesi gerekenleri dışa aktarıyoruz
export { LoginForm } from "./components/login-form"
export { useAuth } from "./hooks/use-auth"
export { loginSchema } from "./schemas/auth.schema"
 
// utils/ veya private bileşenler dışa aktarılmaz!

Bir feature, başka bir feature’ın içindeki private bir bileşeni doğrudan import edemez. Sadece üzerinden izin verilen bileşenlere erişilebilir. Bu kural ESLint ile otomatik denetlenerek spagetti kod oluşumu engellenir.

Eğer bir bileşen, hook veya şema birden fazla feature tarafından kullanılmaya başlanırsa, o kod klasöründen çıkarılıp veya gibi global katmanlara taşınır. Böylece hem kod tekrarı önlenir hem de sınırlar korunur.

Küçük Projeler İçin Uygun Mu?

Her mimari kararın bir bedeli vardır. 3–5 sayfalık basit bir portfolyo veya blog sitesi için her özelliği alt klasörlere bölmek ve üzerinden dışa aktarmak gereksiz bir iş yükü (boilerplate) yaratır.

Küçük projelerde tip tabanlı basit bir yapı dosyaları bulmak için yeterlidir. Feature-driven yapı, küçük bir projede geliştirme hızını artırmak yerine yavaşlatır. Ölçeklenebilirlik ihtiyacı doğduğunda bu geçişi yapmak daha mantıklıdır.

Kuralları Otomatize Etmek

Feature-driven mimariyi manuel olarak korumak, özellikle kalabalık ekiplerde zordur. Sürekli “bu dosya nereye gidecek” veya “ortak klasöre ne zaman taşınacak” tartışması yaşanır.

Bu noktada, mimari kuralları yapay zekâ asistanlarına (Cursor vb.) otomatik uygulatan ViraStack AI paketini kullanabilirsiniz. Projenizin mimari standartlarını belirler, klasör yapınızı korur ve AI’ın bu kuralların dışına çıkarak projeyi çöplüğe çevirmesini engeller.

Originally published at https://www.omergulcicek.com on July 9, 2026.

Feature-Driven Proje Yapısı was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yapay zeka çağının hayatımıza girmesiyle birlikte kod yazma alışkanlıklarımız ciddi derecede değişti. Aslına bakarsanız, bazen elimizden kod yazmanın o saf zevkini aldıklarını hissediyorum. Eskiden bir web sayfasını, mobil uygulamayı ya da bir API endpoint’ini satır satır, handler’larıyla, şemalarıyla kendimiz yazardık. Şimdi ise daha ilk satırı yazarken Claude veya OpenAI fark etmeksizin, iyi bir context verdiğimizde yapay zekanın bizden çok daha iyi dökümante edilmiş bir kod yazacağını biliyoruz. Bu durum, daha ilk satırdan itibaren insanın kod yazma hevesini kırabiliyor, devam edesi gelmiyor.

Bu durum çok sinsi bir soruna yol açıyor: Uzun zaman boyunca sadece agent’ları orkestre ederek, yani onları yönetip yönlendirerek projelerde ilerleyince, en basit bir for döngüsünde veya dilin kendi syntax detaylarında bile el antrenmanımız gidiyor. Çünkü artık kod yazmak eski zevkini vermiyor ve tembelliğe alışıyoruz.

Peki, yapay zeka sonrası dönemde bir yazılım geliştirici olarak kendimi geriye gitmekten nasıl koruyorum ve geliştirmeye devam ediyorum? Kendi hayatımda uyguladığım yöntemi 4 basit adımda anlatmak istedim.

1. El Antrenmanını Kaybetmemek (LeetCode & HackerRank Deneyimi)

Artık yapay zekayı tamamen hayatımızdan çıkarmak ve her şeyi sıfırdan yazmaya çalışmak gerçekçi bir seçenek değil. Ancak o mesleki reflekslerimizin ve pratikliğimizin de yok olmasını istemiyoruz. Bu sorun için kendi geliştirdiğim bir rutini paylaşayım.

LeetCode ve HackerRank gibi platformlardaki algoritma sorularına eskisinden çok daha fazla önem vermeye başladım. Yapay zeka öncesinde de bu soruları çözer, bazen takılır, araştırarak bir sonuca ulaşırdım. Şimdi bir soruyu AI’a verdiğinizde saniyeler içinde çözümü önünüze koyuyor. Ama bunu yaptığımızda ne beynimiz çalışıyor ne de elimiz klavyeye alışıyor.

Yapay zeka döneminde hep söylenen bir şey var: Önemli olan sistem kurmak, orkestre etmek, yapay zeka yapsa bile arka planda ne yaptığını bilmek… Yani computer science ve algoritmalar hâlâ çok önemli.

Ben de bu yüzden haftada birkaç kez, yapay zekadan çözüm aşamasında hiçbir yardım almadan bu platformlardan soru çözüyorum. Bunu tek başıma yaparken hem işin algoritma mantığına odaklanıyorum hem de ana dilim olarak kullandığım Golang ve JavaScript gibi dillerin syntax kısımlarında el antrenmanımı güncel tutuyorum. Çözümü yaparken de düşünce şeklimi sanki teknik bir mülakattaymışım gibi açıklama satırlarına (comment) tek tek yazıyorum.

Altın kuralım şu: Soruyu çözerken kesinlikle yardım almıyorum.

Soruyu kendi başıma çözüp bitirdikten sonra yapay zeka tekrar devreye giriyor. Yazdığım kodu ve açıklama satırlarındaki düşünce yapımı alıp farklı LLM modellerine besliyorum. “Mülakatta olsam bunları söyleyecektim, şimdi beni değerlendir” diyorum. AI beni algoritma mantığı, programlama diline yatkınlık ve Big(O) karmaşıklığı gibi konularda analiz ediyor.

Özellikle Medium ve Hard sorularda mutlaka bir eksiğim çıkıyor. Soruyu çözmüş olsam bile AI ile en optimal yolu tekrar öğrenip çözümümü yukarı çekiyorum. Varsa LLM modeliyle birlikte follow-up sorularını veya “Soruda verilen parametre limiti daha fazla olsaydı ne yapardık?” kısmını tartışıyoruz. Verdiğim prompt gereği bana tartışma sırasında asla doğrudan kod vermiyor, sadece ipuçları vererek beni optimal çözüme ulaştırmaya çalışıyor.

Ek bir avantajı da şu: Büyük bir uygulama veya network servisi yaparken LLM’in daha iyisini yapacağını bildiğiniz için hevesiniz kaçabiliyor demiştim ya, bu algoritma sorularında hedef tek bir odak noktası olduğu ve bir metodun core (çekirdek) kısmını yazdığınız için canınız hiç sıkılmıyor. Hem zihnim çalışıyor hem de el antrenmanım güncel kalıyor. Hatta bazen kendimi zorlamak için tamamen farklı konular ve farklı programlama dilleriyle de denemeler yapıyorum.

2. Sektörün Kült Kitaplarını Derinlemesine Okumak

Daha önce okumak isteyip de bir türlü fırsat ya da zaman bulamadığım o kalın, sektörel kitapları artık yapay zeka ile birlikte çok daha verimli okuma fırsatı yakalıyorum.

NotebookLM gibi sistemler sayesinde bu kitapları part part, bölüm bölüm içeri alıyorum. Okurken merak ettiğim ya da havada kalan konularda hem yapay zekanın gücünü hem de internetteki kaynakları kullanarak derinleşiyorum. Bunu yapay zeka öncesinde yapmak, saatlerce süren kaynak taramaları anlamına geliyordu ve çok zaman alıyordu.

Şu anda ise süreç inanılmaz hızlı işliyor. Bu sayede beynimi tekrar çalıştırmış oluyorum. Daha önce araştırması gözümde büyüyen konulara artık çok daha hızlı giriş yapıp, proof of concept (PoC) çalışmalarını çok hızlı hazırlayabiliyorum. Özetle, daha hızlı ve daha derin öğreniyorum.

3. Low-Level Konular ve Network Programlama

Daha önce denemek istediğim ancak zaman azlığından, fırsat bulamamaktan ya da daha doğrusu internette yeterince temiz kaynak olmamasından dolayı giremediğim alanlar vardı: Binary inceleme, low-level programlama dilleri, network programlama gibi konular… Artık bunlara çok daha hızlı dalış yapabiliyorum.

Örneğin önceki şirketimde ihtiyaç duyduğumuz spesifik bir protokolü araştırmıştım. Genellikle bu tarz konularda internette hazır döküman veya kaynak bulmak çok zor oluyor. O dönem bir proof of concept hazırlamam günlerce sürmüştü.

Ancak artık LLM’ler sayesinde bu protokolün tam olarak ne olduğunu, içinde ne taşıdığını, RFC standartlarını ve OSI modelini hızlıca özetleterek bulabiliyorum. Çok hızlı bir demo hazırlayıp protokolün mantığını kavrayabiliyorum. Aslında bu durum, yapay zekanın biz geliştiricilere verdiği muazzam bir süper güç.

4. Büyük Open Source Projeleri Analiz Etmek

İncelemek istediğim ama kod tabanının büyüklüğü ve vakit darlığı yüzünden gözümün korktuğu açık kaynaklı (open source) projeleri artık yapay zeka ile birlikte analiz ediyorum.

Özellikle GitHub’da bulunan, uzun zamandır bakmak istediğim ancak çok zamanımı alacağını düşündüğüm için ertelediğim büyük projelere yapay zeka modelini de ortak ediyorum. Kod tabanını açıp projenin tam olarak ne iş yaptığını kendime özetletiyorum. Projenin core metotlarını ve modüllerini bulduruyorum. İçeride hangi algoritmaların, nasıl bir mimariyle kullanıldığını çözümlüyorum.

Yapay zeka öncesinde bu kadar büyük codebase’lerin içinde kaybolup gitmek çok kolayken ve inanılmaz zaman alıyorken, artık süreci çok daha hızlı ve efektif bir şekilde yönetebiliyorum. Bu da doğrudan mimari vizyonumu geliştiriyor ve kendime yeni şeyler katmamı sağlıyor.

Özetlemek gerekirse; yapay zeka elimizden amelelik diye tabir edebileceğimiz uzun kod bloklarını yazma işini aldı evet, ama bizi daha stratejik ve derin düşünmeye zorluyor. Önemli olan bu araçları bizi tembelleştiren birer unsur olarak değil, bizi yukarı taşıyan birer kaldıraç olarak kullanabilmek.

Originally published at https://metinagaoglu.com.

Yapay Zeka Çağında Körelmemek: Bir Yazılımcı Olarak Kendimi Nasıl Güncel Tutuyorum? was originally published in Kodcular on Medium, where people are continuing the conversation by highlighting and responding to this story.