sade.dev

İndeks Yönetimi: Eksik Yavaşlatır, Fazlası Yazmayı Öldürür

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 05 Sep 2026 00:00:00 GMT

İki karşıt ekip gördüm. Biri tabloya hiç indeks koymamıştı — her sorgu bir sequential scan, her liste sayfası saniyeler sürüyordu. Diğeri tam tersini yapmıştı: “ne olur ne olmaz” diye her kolona bir indeks açmıştı ve şimdi her INSERT ağır aksak ilerliyordu.

İkisi de aynı yanılgının iki ucu: indeksi ücretsiz bir hız kaynağı sanmak.

İndeks ücretsiz hız değildir

Bir indeks okumayı hızlandırır, çünkü veritabanı tüm tabloyu taramak yerine sıralı bir yapıya bakar. Ama o sıralı yapı kendi kendine güncel kalmaz: tablodaki bir INSERT, o tablonun her indeksine bir girdi yazar; bir UPDATE de indeksli bir kolona dokunduğu anda aynısını yapar. İstisnalar var — indeksli hiçbir kolonu değiştirmeyen HOT güncellemesi indekslere dokunmaz, kısmi indeks yüklemi dışında kalan satırlar için güncellenmez, DELETE ise indeks girdilerini temizlemeyi VACUUM’a bırakır — ama bunlar istisna, varsayılan değil.

Yani her indeks bir takastır: okuma hızını, yazma maliyetiyle satın alırsınız. Beş indeksli bir tabloya tek satır eklemek, altı yapıyı birden güncellemektir. İndeks “bedava okuma hızı” değil, “yazmayla ödenmiş okuma hızı”dır.

Eksik indeks: tahmin değil, ölçüm

Eksik indeksi sorgu planından bulun, tahminden değil:

EXPLAIN ANALYZE
SELECT * FROM orders WHERE status = 'pending';

Çıktıda büyük bir tabloda Seq Scan görüyorsanız ve sorgu satırların küçük bir kısmını döndürüyorsa, muhtemelen bir indeks eksiktir. pg_stat_user_tables tablosunda seq_scan sayısı yüksek olan büyük tabloları tarayın — bunlar adaylarınızdır.

İndeksi gerçek, yavaş bir sorgu için ekleyin. “İleride lazım olabilir” diye eklenen indeks, spekülatif genelliğin veritabanı katmanındaki hâlidir.

Fazla indeks: kullanılmayanı bul

Ters yönde, hiç kullanılmayan indeksler her yazmayı boş yere pahalılaştırır. Onları da ölçümle bulun:

SELECT indexrelname, idx_scan
FROM pg_stat_user_indexes
WHERE idx_scan = 0;

idx_scan = 0 olan bir indeks hiç okuma hızlandırmıyor ama her yazmaya maliyet ekliyor demektir. (Primary key ve unique kısıtların indekslerini elbette koruyun.) Bu, veri yoğunluklu sistemlerin yazma kırılma noktasında sayılan ilk temizliktir.

Doğru indeksi seçmek

İndeks “var/yok”tan ibaret değildir; doğru türü ve şekli seçmek önemlidir:

Bileşik indekste kolon sırası. (a, b) indeksi, a’da eşitlik + b’de aralık sorgusuna hizmet eder; b’de tek başına yapılan bir arama da bu indeksi kullanabilir ama taranan indeks bölümünü daraltmaz — PostgreSQL 18 öncesinde indeksin tamamı taranır, 18’den itibaren skip scan optimizasyonu bunu daraltır. Eşitlikle filtrelenen kolonu başa, aralıkla filtreleneni sona koyun.
Kısmi indeks (partial). Sorgu hep aynı alt kümeye bakıyorsa indeksi de o alt kümeyle sınırlayın: CREATE INDEX ... WHERE status = 'active'. Daha küçük indeks, daha ucuz bakım.
Covering indeks. INCLUDE ile sık okunan kolonları indekse ekleyip veritabanının tabloya hiç gitmemesini sağlayabilirsiniz.
B-tree dışı türler. Eşitlik/sıralama için B-tree; jsonb ve tam metin için GIN; saf sıralı, append ağırlıklı veri için küçük ve ucuz BRIN.

Duplikat ve örtüşen indeksler

(a) üzerindeki bir indeks, zaten (a, b) indeksiniz varsa gereksizdir — bileşik indeks a ile başlayan sorgulara da hizmet eder. Bu tür örtüşmeleri periyodik olarak temizleyin; her biri sessiz bir yazma vergisidir.

Denge sorgu planıyla kurulur

Tek kural: indeksi ne tahminle ekleyin ne tahminle silin. Bir indeks, gerçek bir sorgu planı onu istediği için eklenir; bir indeks, istatistikler onu kimsenin kullanmadığını gösterdiği için silinir. Eksik ile fazla arasındaki denge, hislerle değil, EXPLAIN ANALYZE ve pg_stat_user_indexes ile kurulur.

İndeks yönetimi, “daha çok indeks daha iyi” sanısından kurtulmakla başlar. Her indeks bir okuma kazancı ve bir yazma maliyetidir; iyi yönetim, bu ikisini ölçerek dengede tutmaktır.

Eksik indeks sorguyu yavaşlatır; fazlası ise tüm tabloyu. İkisinden de ölçüm korur.

Canlıda Sıfır Kesintiyle Şema Değiştirmek

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 29 Aug 2026 00:00:00 GMT

Bir deploy, 50 milyon satırlık bir tabloda tek bir ALTER TABLE çalıştırdı ve tabloyu dört dakika kilitledi. Dört dakika boyunca o tabloya değen her istek bekledi; site fiilen çöktü. Migration’ın kendisi doğruydu — sorun, onun tek adımda yapılmasıydı.

Tehlikeli olan şema değişikliği değildir. Tehlikeli olan, şema değişikliğini tek seferde, geri uyumluluğu düşünmeden yapmaktır.

Lock’u kim alır

Her şema değişikliği aynı maliyette değildir. Modern PostgreSQL’de sabit DEFAULT ile kolon eklemek bir metadata işlemidir — hızlıdır. Asıl tehlike, tabloyu uzun süre kilitleyen işlemlerdedir:

CREATE INDEX — CONCURRENTLY olmadan tabloyu yazmaya kapatır.
Tabloyu yeniden yazan ALTER COLUMN ... TYPE değişiklikleri.
Tüm tabloyu tarayan NOT NULL, CHECK veya foreign key eklemeleri.

Bu işlemler güçlü bir lock alır; ACCESS EXCLUSIVE alanlar — tablo yeniden yazımı ya da NOT NULL/CHECK eklemesi — tabloya değen her sorguyu, okuma dahil, kuyruğa sokar. Geri kalanı yalnızca yazmaları bloklar. Tablo büyükse kuyruk uzar.

Tehlikeli olan tek adımdır

Çözüm migration yapmamak değil; her tehlikeli migration’ı, her biri tek başına güvenli ve geri uyumlu olan küçük adımlara bölmektir. Bunun adı expand-contract (genişlet–daralt) kalıbıdır.

Bir kolonu yeniden adlandırmak istediğinizi düşünün. Tek adımda RENAME COLUMN, eski kolonu okuyan çalışan kodu anında kırar. Bunun yerine üç deploy:

Genişlet. Yeni kolonu ekle. Kod hem eskiye hem yeniye yazsın, hâlâ eskiden okusun.
Geçiş. Eski veriyi yeni kolona batch’ler hâlinde taşı. Kod artık yeniden okusun.
Daralt. Eski kolonu sil.

Her adım, hem bir önceki sürümdeki kod hem de yeni kod ile çalışır. Hiçbir an, çalışan kod ile şema uyumsuz değildir.

Güvenli reçeteler

Sık yapılan değişikliklerin kesintisiz hâlleri:

Yeni NOT NULL kolon. Tek adımda NOT NULL eklemek tabloyu tarar. Bölün:

-- 1. Önce nullable ekle
ALTER TABLE orders ADD COLUMN status text;

-- 2. Mevcut satırları batch'ler hâlinde doldur (uygulama tarafında)

-- 3. Kısıtı önce doğrulamadan ekle, sonra ayrı adımda doğrula
ALTER TABLE orders ADD CONSTRAINT orders_status_not_null
    CHECK (status IS NOT NULL) NOT VALID;
ALTER TABLE orders VALIDATE CONSTRAINT orders_status_not_null;

NOT VALID ile eklenen kısıt yeni satırlar için hemen geçerlidir ama mevcut satırları taramaz; VALIDATE ise tabloyu yalnızca SHARE UPDATE EXCLUSIVE lock ile tarar — yazmaları engellemez.

İndeks. Her zaman CONCURRENTLY:

CREATE INDEX CONCURRENTLY idx_orders_status ON orders (status);

Foreign key. Aynı iki adımlı kalıp: önce ADD CONSTRAINT ... NOT VALID, sonra VALIDATE CONSTRAINT.

lock_timeout. Bir migration, uzun süren bir sorgunun arkasında lock için beklerken kendisi de arkasındaki her şeyi bloklar. Bunu önlemek için migration oturumuna kısa bir lock_timeout verin — lock hemen alınamıyorsa migration beklemek yerine başarısız olsun, siz tekrar deneyin.

Kod ve şema birlikte uyumlu olmalı

Expand-contract’ın özü tek bir kuralda: her ara adımda, hem çalışmakta olan eski kod hem de yeni kod mevcut şema ile çalışabilmeli.

Veritabanı şeması, ileride lazım olur yazısında “tek yönlü kapı” dediğim şeydir — geri almak pahalıdır. Bu yüzden değişikliği büyük ve geri dönülmez tek bir adım olarak değil, her biri ayrı ayrı geri alınabilir küçük adımlar olarak tasarlayın.

Sıfır kesintili migration bir araç değil, bir disiplindir: her şema değişikliğini, çalışan kodun hiç fark etmeyeceği kadar küçük adımlara bölmek.

Tehlikeli olan değişikliğin kendisi değil, onu tek nefeste yapmaktır.

Read/Write Splitting: Okuma ve Yazma Yükünü Ayırmak

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 22 Aug 2026 00:00:00 GMT

Primary veritabanının CPU’su sürekli tavandaydı. İlginç olan şuydu: yazma oranı düşüktü. Yükün neredeyse tamamı okumaydı — rapor sayfaları, listeleme endpoint’leri, arama. Tek bir primary, kendisine hiç ihtiyaç duymayan bir sürü okumayı taşımaya çalışıyordu.

Okuma ve yazma yükünü ayırmak — read/write splitting — bu tablonun bilinen çözümü. Ama doğru zamanda ve doğru tuzakların farkında uygulanmazsa, çözdüğünden çok problem getirir.

Çoğu yük okuma ağırlıklıdır

Trafiğin ne kadarının okuma olduğu iş yüküne bağlıdır: standart OLTP benchmark’larının ölçümünde TPC-E %90,69 okumadır, TPC-C ise %65,71’de kalır — yani kendi oranınızı varsaymak yerine ölçün. Her sipariş bir kez yazılır, ama onlarca kez okunur: listede, detayda, raporda, panelde. Bu asimetri, read/write splitting’i cazip kılan şeydir — çünkü ölçeklemeniz gereken taraf bellidir.

Önce: bu gerçekten bir kapasite sorunu mu?

Replica eklemeden önce durun. Primary’nin dolu olması her zaman “kapasite bitti” demek değildir. Çoğu zaman tek bir eksik indeks, primary’yi olduğundan kat kat meşgul gösterir.

Bir replica eklemek — yeni bir sunucu, replication kurulumu, lag izleme — aslında bir CREATE INDEX’in çözeceği bir problemi pahalıya satın almak olabilir. Veri yoğunluklu sistemlerin kırılma noktaları yazısındaki sıra nettir: önce indeks disiplini, sonra replica. Bu sırayı atlamayın.

Sorgularınızı EXPLAIN ANALYZE ile ölçün. Primary, doğru indekslenmiş sorgular altında gerçekten doyuyorsa — işte o zaman replica.

Replica okumayı ölçekler, yazmayı değil

Net olalım: bir read replica, yazma kapasitenize hiçbir şey katmaz. Aynı yazmalar her replica’da yeniden oynanır. Replica okuma yükü problemini çözer; yazma yükü probleminiz varsa replica yanlış araçtır.

Laravel’de kurulum

Laravel, okuma/yazma bağlantı ayrımını doğal destekler:

// config/database.php
'pgsql' => [
    'driver' => 'pgsql',
    'read'   => ['host' => ['10.0.0.2']],   // replica
    'write'  => ['host' => ['10.0.0.1']],   // primary
    'sticky' => true,
    // ...ortak ayarlar
],

SELECT’ler replica’ya, INSERT/UPDATE/DELETE’ler primary’ye gider. Replica’nın kendi bağlantı havuzu olur — primary’ninkinden ayrı; pgBouncer kullanıyorsanız ikisi ayrı havuzdur.

Replication lag: asıl fatura

Replica, primary’nin birkaç milisaniye — yük altında birkaç saniye — gerisindedir. Bu gecikme, read/write splitting’in gerçek bedelidir ve adı read-after-write problemidir.

sticky => true bunu kısmen çözer: bir istek içinde yazma yaptıysanız, aynı istekteki sonraki okumalar primary’ye gider. Ama sticky yalnızca tek bir istek sınırında çalışır.

Sınırın dışı hâlâ açıktır: kullanıcı profilini günceller (istek 1, primary’ye yazıldı), sonraki sayfaya geçer (istek 2, replica’dan okur) ve henüz replica’da oynanmamış eski profilini görür. Kullanıcı kendi yazdığı veriyi bayat görür. Bu bir bug gibi görünür ama aslında mimarinin kabul ettiği bir ödündür — bilerek kabul edilmesi gereken bir ödün.

Sorgu sınıflandırma disiplini

Read/write splitting’i kurmak, her okumanın şu soruya cevap vermesini gerektirir: bu sorgu bayat veri okuyabilir mi?

Replica’dan okunabilir: listeler, raporlar, arama sonuçları, paneller. Birkaç saniye gecikme önemsiz.
Primary’den okunmalı: hesap bakiyesi, stok adedi, yetki kontrolü, bir yazma kararının dayandığı her okuma.

Bu sınıflandırma artık mimarinin bir parçasıdır ve dokümante edilmesi gerekir. Yeni gelen bir geliştiricinin “bu sorgu nereden okumalı” sorusuna bakacak bir yeri olmalı — yoksa sınıflandırma sessizce çürür.

Ne zaman gerçekten gerekir

Read/write splitting şu üç koşul birlikte sağlandığında doğru hamledir:

İndeks disiplini tamamlanmış; sorgular doğru indeksli ve hâlâ primary doyuyor.
Yük ölçülmüş biçimde okuma ağırlıklı.
Bayat-okuma sınıflandırmasını yapıp dokümante edecek disiplin var.

Bunlardan biri eksikse, replica’yı ertelemek daha ucuzdur.

Read/write splitting, dikey büyümeden ucuz bir ölçek hamlesidir — ama bedava değildir. Bedeli replication lag’dir ve onu görmezden gelmek, kullanıcıya kendi verisini eski göstermekle ödenir.

Okumayı ayırmadan önce, hangi okumanın bayatlığa dayanabileceğini bilin.

Redis Koymadan Önce: Doğru Cache Stratejisi

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 15 Aug 2026 00:00:00 GMT

Bir ekip “site yavaş” diye Redis cache ekledi. Bir hafta sonra destek kuyruğu doldu: “Fiyatı güncelledim ama eski fiyat görünüyor.” Cache yavaşlığı çözmüştü — ve sessizce yeni bir problem yaratmıştı.

Cache eklemek bedava bir performans kazancı değildir. Tazeliği hıza takas etmektir; bu takası bilerek yapmadıysanız, fatura bir bug olarak geri gelir.

Cache bir tutarlılık ödünüdür

Bir değeri cache’lediğiniz an şunu kabul etmiş olursunuz: birileri, bir süreliğine, eski veriyi görebilir. Cache hiçbir zaman “daha hızlı veritabanı” değildir; “kabul edilmiş bayatlık karşılığında hız”dır.

Bu yüzden ilk soru teknik değil: bu veri ne kadar bayat olabilir? Cevabı “hiç” olan bir veri — bir hesap bakiyesi, bir stok adedi — cache’lenmeden önce iki kez düşünülmelidir.

Önce sorulacak sorular

Redis’i açmadan önce:

Bu gerçekten bir okuma darboğazı mı? “Site yavaş” bir hipotezdir, ölçüm değil. Yavaşlığın kaynağını görmeden cache eklemek, bilinmeyen bir şeyin üstünü örtmektir.
Yavaşlık aslında eksik bir indeks mi? Cache, kötü bir sorgunun üstünü örter ama onu çözmez. Bir CREATE INDEX’in çözeceği şeyi cache’le gizlemek, problemi taşımaktır — veri yoğunluklu sistemlerdeki yanlış kırılma noktası tam olarak budur.
Bu veri ne kadar bayat kalabilir? Cevap, hangi stratejiyi seçeceğinizi belirler.

Invalidation neden zor

Yazılımın iki zor probleminden biri olarak anılır cache invalidation — ve abartı değil. Cache’i koymak kolaydır; onu doğru anda temizlemek zordur.

Çünkü bir cache değeri, onu etkileyen her yazma yolunda temizlenmelidir. Ürün fiyatı yalnızca “ürünü düzenle” ekranından değil; toplu fiyat güncellemesinden, bir indirim işinden, bir admin script’inden de değişir. Bu yolların hepsini bulup cache’i temizlemek — işte zor olan bu. Bir tanesini kaçırırsanız, yazının başındaki destek talebini alırsınız.

İki strateji

Pratikte iki yol var:

TTL tabanlı. Değere bir ömür biçersiniz — 60 saniye, 5 dakika. Süre dolunca cache kendini tazeler. Basit, sağlam, her yazma yolunu bilmeyi gerektirmez. Karşılığında: TTL süresi kadar bayatlık kabul edersiniz.
Açık invalidation. Veri değiştiğinde cache’i elle silersiniz. Kesin ve tazedir — ama yalnızca her yazma yolunu eksiksiz yakalarsanız.

Varsayılanım TTL’dir. Sıkıcı, öngörülebilir ve unutulan bir yazma yolu yüzünden sessizce bozulmaz. Açık invalidation’a yalnızca bayatlık gerçekten kabul edilemezken ve yazma yollarının sayısı sınırlı ve bilinirken geçerim. Çoğu zaman ikisi birlikte kullanılır: kısa bir TTL bir güvenlik ağı olarak, açık invalidation hız için.

Cache yazmayı azaltmaz

Sık yapılan bir hata: yazma yükü altındaki bir sistemi cache ekleyerek kurtarmaya çalışmak. Cache okuma yükünü azaltır; yazma yüküne hiçbir etkisi yoktur — aksine, invalidation’ın kendisi ek yazma işidir. Probleminiz yazma tarafındaysa, cache yanlış araçtır.

Pratik kalıplar

Cache-aside. Oku: önce cache’e bak, yoksa veritabanından al ve cache’e yaz. En yaygın ve en anlaşılır kalıp.
Stampede koruması. Popüler bir anahtarın TTL’i dolduğu an yüzlerce istek aynı anda veritabanına gider. Cache miss’te kısa bir lock ile yalnızca bir isteğin veritabanına gitmesini sağlayın.
Anahtar disiplini. Cache anahtarlarını namespace’leyin — shared Redis namespace izolasyonu notundaki kalıp, cache anahtarları için de geçerlidir.

Cache, yavaş bir sistemin çözümü değil; ölçülmüş bir okuma darboğazının, bilinçli bir tutarlılık ödünüyle hafifletilmesidir. Invalidation planı olmadan eklenen cache, hızlandırdığından fazlasını borç olarak geri alır.

Cache koymadan önce sorun: bu veri ne kadar eski olabilir — ve onu kim temizleyecek?

NoSQL Tuzağı: "Şeması Yok" Diye Başlamak

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 08 Aug 2026 00:00:00 GMT

“Şeması yok, hızlı ilerleriz” diyerek MongoDB seçen bir projeyi iki yıl sonra gördüm. Her okuma savunmacıydı: data?.user?.address?.city ?? null. Sebep basitti — hiçbir belge bir diğeriyle tam olarak aynı şekle sahip değildi. Şema kaybolmamıştı; sadece veritabanından çıkıp her okuma kodu satırına dağılmıştı.

”Şemasız” bir yanılgı

Şemasız veri diye bir şey yoktur. Verinin her zaman bir şekli vardır: bir kullanıcının e-postası, bir siparişin kalemleri, bir faturanın tarihi. Soru, şekil olup olmadığı değil; o şeklin nerede tanımlandığı.

İki seçenek var. Şema ya veritabanında durur ve veritabanı tarafından zorlanır; ya da uygulama kodunda durur ve herkesin ona uyduğu varsayılır. “Şemasız” demek, ikincisini seçmektir — şemayı silmek değil, onu zorlanmayan bir yere taşımak.

Şema nereye taşınır

Veritabanı şemayı zorlamayı bıraktığında, o iş ortadan kalkmaz; şu yerlere dağılır:

Her okumaya. Kod, gelen belgenin beklenen alanlara sahip olduğunu artık varsayamaz; her alanı savunmacı biçimde kontrol eder.
Her yazmaya. Doğru şekli yazdığınızın garantisi yoktur; yalnızca umut vardır.
Dağınık doğrulama koduna. Veritabanının tek satırda yaptığı NOT NULL, tip kontrolü, foreign key — hepsi elle yazılmış kontrollere dönüşür.
Ekibin kafasına. “O alan bazen string, bazen array” bilgisi, dokümante edilmemiş bir kabile bilgisi olur.

Şema bürokrasi değildir; veritabanının sizin yerinize ücretsiz yaptığı doğrulamadır. Onu reddetmek faturayı silmek değil, başka birine kesmektir.

Çarpılan krizler

“Şemasız” rahatlığıyla başlayan projeler er ya da geç şunlara çarpar:

Veri drift’i. Zamanla belgenin on farklı sürümü aynı koleksiyonda yaşar. 2023’te yazılan kayıt, 2026’da yazılanla aynı şekilde değildir ve hiçbir migration bunu zorlamamıştır.
Referans bütünlüğü yok. Var olmayan bir kullanıcıya işaret eden bir sipariş, veritabanı tarafından engellenmez. Yetim kayıtlar sessizce birikir.
Migration bir uygulama işine dönüşür. İlişkisel dünyada tek bir ALTER TABLE ile yapılan şey, burada milyonlarca belgeyi tek tek gezen, batch’lenmesi gereken bir script olur.

Bunlar küçük projede görünmez; tam da projenin büyüdüğü, ekibin değiştiği, kimsenin “o alan neden bazen yok” sorusunu cevaplayamadığı anda patlar.

NoSQL’in gerçekten doğru olduğu yerler

Bu, NoSQL’e karşı bir yazı değil. NoSQL’in gerçek ve haklı kullanımları var:

Tek bir primary’nin yazma kapasitesini aşan, gerçekten yatay ölçek gerektiren yükler — veri yoğunluklu sistemlerdeki en zor kırılma noktası.
Doğası gereği gerçekten heterojen belgeler.
Belirli erişim desenleri — saf key-value, wide-column, graph.

Tuzak NoSQL değil; NoSQL’i bu gerçek güçlerinden biri için değil, sadece “şema istemiyorum” diye seçmektir. Doğru araç, yanlış gerekçe.

Esneklik istiyorsanız PostgreSQL zaten veriyor

“Bazı alanlar esnek olsun” ihtiyacı gerçekse, bunun için tüm bütünlüğü feda etmeniz gerekmez. PostgreSQL’in jsonb sütunu, ilişkisel tablonun bütünlüğü içinde esnek bir belge alanı verir — PostgreSQL her şeye yeter mi yazısında değindiğim gibi. Sabit olan alanlar şema olarak kalır, gerçekten değişken kısım jsonb’de durur. İkisinin en iyisi, hem de tek sistemde.

Şema bir yük değil, bir kalkandır. Onu veritabanından kaldırdığınızda kaybolmaz — yalnızca sizi koruduğu yerden çıkıp, sizi koruyamayacağı yere taşınır.

“Şemasız” diye bir şey yoktur; yalnızca “şemayı kim zorluyor” sorusu vardır.

PostgreSQL Her Şeye Yeter mi?

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 01 Aug 2026 00:00:00 GMT

Bir mimari planında, daha tek kullanıcı yokken şu liste vardı: kalıcı veri için PostgreSQL, arama için Elasticsearch, cache için Redis, esnek belgeler için MongoDB, kuyruk için RabbitMQ. Beş ayrı veri sistemi — beşinin de yedeği, monitoring’i, sürüm yükseltmesi ve kendine özgü hata modu.

O listenin büyük kısmını, uzun bir süre boyunca, tek başına PostgreSQL taşır. Soru “PostgreSQL bunu yapabilir mi” değil; “bu beş sistemin operasyon yükünü gerçekten satın aldınız mı”.

PostgreSQL’in az bilinen genişliği

PostgreSQL’i sadece bir tablo-satır deposu sanmak, yeteneklerinin küçük bir kısmını kullanmaktır. Sık sık ayrı bir sistem getirten ihtiyaçların çoğu zaten içinde:

Tam metin arama. tsvector, tsquery ve GIN index ile gövdeli bir arama. Çoğu uygulamanın “ürün ara”, “yazı ara” ihtiyacını dilsel sapma, ağırlıklandırma ve sıralama dahil karşılar.
Doküman saklama. jsonb sütunu, GIN index’iyle birlikte sorgulanabilir bir belge deposudur. Şema esnekliği isteyen alanları, ilişkisel tablonun içinde tutabilirsiniz.
Kuyruk. SELECT ... FOR UPDATE SKIP LOCKED ve LISTEN/NOTIFY, orta hacimli bir iş kuyruğunu ayrı bir broker olmadan çalıştırır. Laravel’in database queue driver’ı bunun SKIP LOCKED tarafını kullanır — worker’ları LISTEN/NOTIFY sinyali beklemek yerine kuyruk tablosunu belirli aralıklarla yoklar.
Analitik sorgular. Window function’lar, CTE’ler, materialized view’lar — ayrı bir analitik veritabanına gitmeden ciddi raporlama.
Coğrafi veri. PostGIS eklentisiyle konum sorguları.

Bu özellikler “var ama kullanılmıyor” değil; production’da güvenilir biçimde çalışan, olgun yeteneklerdir.

Tek sistemin sessiz getirisi

Her yeni veri sistemi yalnızca bir kutu değil; bir bakım yükümlülüğüdür. Tek sistemde kalmanın getirisi:

Tek yedek hattı. Bir tane backup/restore prosedürü, bir tane kurtarma tatbikatı.
Tek izleme hedefi. Öğrenilecek bir metrik seti, kurulacak bir alarm düzeni.
Çapraz tutarlılık. En önemlisi bu. Arama indeksiniz ile veriniz aynı veritabanındaysa aralarında drift olamaz — ikisi aynı transaction’da güncellenir. Ayrı bir Elasticsearch ise eninde sonunda veriyle senkronizasyonu bozulur ve onu düzeltmek ayrı bir iş kalemine dönüşür.
Tek zihinsel model. Ekip tek bir sistemin tuhaflıklarını öğrenir, beş sistemin değil.

Bu, boring architecture yazısındaki innovation token mantığının veri katmanındaki hâlidir: her yeni sistem bir token ve token sınırlı.

Sınır nerede başlar

PostgreSQL her şeye yetmez — dürüst sınırları var ve onları görmezden gelmek de bir hata olur:

Arama. Yazım hatası toleransı, gelişmiş alaka düzeyi ayarı, faceted search ve çok dilli analiz ciddi ölçekte gerektiğinde, adanmış bir arama motoru gerçekten kazandırır.
Kuyruk. Çok yüksek throughput, karmaşık yönlendirme ya da çok tüketicili fan-out gerektiğinde gerçek bir message broker doğru araçtır. PostgreSQL kuyruğu orta hacimde rahat, uç hacimde değil.
Yazma throughput’u. Tek primary’nin fsync kapasitesini aşan sürekli yazma — bu, veri yoğunluklu sistemlerdeki en zor kırılma noktası ve gerçek bir sınır.

Bu sınırlardan birine çarptığınızda ek sistem getirmek doğru karardır. Çarpmadan getirmek ise yalnızca bir tahmin.

Karar: önce PostgreSQL, sonra ölçüm

Kural sade: yeni bir projede, PostgreSQL’in yapabildiği her şeyi PostgreSQL’e yaptırın. Arama, kuyruk, cache benzeri ihtiyaçların ilk durağı o olsun. Ayrı bir sistem, ancak ölçülmüş bir sınır aşıldığında gelsin — bir histen, bir blog yazısından ya da CV kaygısından değil.

Çoğu ekip PostgreSQL’in belki %20’sini kullanır, sonra “yetmiyor” der. Yetmeyen çoğu zaman PostgreSQL değil, onu tanıma çabasıdır.

PostgreSQL her şeye yetmez — ama sandığınızdan çok daha fazlasına yeter. İkinci bir veri sistemi getirmeden önce, birincisinin gerçekten sonuna gelip gelmediğinizi sorun.

Önce PostgreSQL; gerisi ölçümle gelsin.

Bir Sistemin "Gereğinden Karmaşık" Olduğunu Gösteren Sinyaller

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 25 Jul 2026 00:00:00 GMT

Ekibe yeni katılan bir mühendis ilk haftasının sonunda sordu: “Tek bir alan eklemek neden iki gün sürüyor?” Soru masumdu, teşhis netti. Kimse o sistemi bir gün oturup “karmaşıklaştıralım” diye kararlaştırmamıştı. Karmaşıklık öylece birikmişti.

Sorun da burada: karmaşıklık tek bir kararla gelmez, fark edilmeden birikir. Onu geri almak için önce onu görebilmek gerekir.

Karmaşıklık nasıl birikir

Hiçbir karmaşık sistem, karmaşık olmaya karar vermez. Her adım tek başına makul görünür: “şimdilik bir interface açalım”, “bu duruma bir flag koyalım”, “araya bir katman daha”. Her biri küçük, her biri savunulabilir.

Toplamları savunulabilir değil. Karmaşıklık bir olay değil, bir birikim — ve birikim, adı konmadığı sürece görünmez. Bu yüzden sadeleştirme bir his ile başlayamaz; somut sinyallerle başlar.

Somut sinyaller

Bir sistemin gereğinden karmaşık olduğunu söyleyen, tartışmaya kapalı kırmızı çizgiler:

Tek bir özelliği anlamak için çok sayıda dosya açıyorsunuz. Bir isteğin nereye gittiğini görmek altı dosya ve dört dolaylılık gerektiriyorsa, problem sizde değil, yapıdadır.
Tek satırlık bir değişiklik bir düzine dosyaya dokunuyor. Bir alan eklemek için migration, model, DTO, mapper, interface, factory, test fixture… Değişimin maliyeti, değişimin büyüklüğüyle orantılı değil.
Tek implementasyonlu interface’ler. “İhtimale karşı” açılmış, asla ikinci implementasyonu gelmemiş soyutlamalar. Bu, spekülatif genelliğin kod tabanında bıraktığı tortudur.
Onboarding haftalar sürüyor. Olgun ve sade bir sistemde yeni mühendis ilk günlerde üretkendir. Haftalar sürüyorsa, kod kendini anlatmıyordur.
Kimse sistemi tahtaya çizemiyor. “Şu kutu şuraya bağlı” diye anlatılamayan bir mimari, anlaşılmıyor demektir.
Test kurulumu testin kendisinden uzun. Bir davranışı test etmek için kurulması gereken on mock, o davranışın çok fazla şeye bağlı olduğunun itirafıdır.
“Oraya dokunma, kırılır.” Bir kod bölgesi dokunulmaz ilan edilmişse, o bölge zaten kırıktır — sadece henüz patlamamıştır.
Kimsenin kullanmadığı config, flag ve seçenekler. Açılıp unutulmuş her seçenek, kodu her okuyanın hesaba katması gereken bir daldır.

Bir sistemde bu sinyallerden ikisi-üçü varsa, tartışma “karmaşık mı” değil, “nereden başlayacağız”dır.

Sadeleştirmeye nereden başlanır

Sadeleştirme bir yeniden yazım değildir; çoğu zaman bir çıkarma işlemidir. Sırayla:

Ölü kodu sil. Kullanılmayan flag, çağrılmayan method, ulaşılmayan branch. En düşük riskli, en yüksek getirili adım — silinen kodun bug’ı olmaz.
Tek implementasyonlu interface’leri çökert. Soyutlama gerçek bir ikinci kullanım kazanana kadar somut sınıfı doğrudan kullanın. Dikiş gerçekten gerektiğinde — ihtiyaç kanıtlandığında — birkaç saatlik bir refactor’la geri gelir.
Erken dolaylılığı satır içine al. Tek yerden çağrılan, sadece argümanı bir başka fonksiyona geçiren katmanları kaldırın.
Sınırları netleştir. Geriye kalan karmaşıklığı modüler monolitteki gibi net sınırların arkasına toplayın — böylece bir dahaki birikim erken görünür.

Her adımdan sonra durun ve ölçün. Sadeleştirme de aşırıya kaçabilir; amaç “en az kod” değil, “en az gereksiz kod”.

Karmaşıklık her zaman kötü değil

Önemli bir ayrım: karmaşıklığın iki türü var. Fred Brooks’un kavramlarıyla — özsel (essential) ve tesadüfi (accidental).

Özsel karmaşıklık domain’in kendisinden gelir. Vergi hesabı karmaşıktır, çünkü vergi mevzuatı karmaşıktır; bunu silemezsiniz, sadece dürüstçe modelleyebilirsiniz. Tesadüfi karmaşıklık ise sizin eklediğinizdir: gereksiz katman, erken soyutlama, unutulmuş flag.

Sadeleştirmenin hedefi tesadüfi olanı temizlemektir — özsel olanı değil. Bir sistemi “çok basit” yapıp domain’in gerçek karmaşıklığını görmezden gelmek de bir hatadır; o karmaşıklık silinmez, sadece yanlış yere — genelde çağıran kodun içine — taşınır.

İyi mimari, domain ne kadar karmaşıksa o kadar karmaşıktır; daha fazlası değil.

Karmaşıklık fark edilmeden birikir; bu yüzden onu fark edilir kılan sinyalleri ezbere bilmek bir mühendislik becerisidir. Sinyali adlandıramıyorsanız, sadeleştirmeye de başlayamazsınız.

Bir sistemi basit tutmak, onu basit kurmaktan daha çok emek ister — ve o emeğe değer.

Dış Servis Entegrasyonlarında Circuit Breaker

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 18 Jul 2026 00:00:00 GMT

Bir SMS sağlayıcısı yavaşladı — çökmedi bile, sadece yanıt süresi 30 saniyeye çıktı. Yarım saat içinde bütün uygulama yanıt veremez hâle geldi; SMS ile hiç ilgisi olmayan endpoint’ler bile zaman aşımına uğruyordu. Tek bir yavaş dış servis, koca sistemi birlikte aşağı çekmişti.

Bir dış servis er ya da geç çöker. Soru o değil. Soru şu: sizin sisteminiz onunla birlikte mi çökecek?

Zincirleme çöküş nasıl olur

Mantık basit ve acımasız. Yavaş bir dış çağrı, onu yapan worker’ı — ya da PHP-FPM process’ini — kendine kilitler. Çağrı 30 saniye sürerse, o process 30 saniye boyunca başka hiçbir isteğe bakamaz.

İstekler birikir, process havuzu dolar. Havuz dolunca — SMS ile hiç ilgisi olmayanlar dâhil — yeni istekler de bekler. Sağlıklı endpoint’leriniz, hasta bir bağımlılık yüzünden ölür. Buna cascading failure denir ve neredeyse her zaman bir yavaşlamayla başlar.

İlk savunma: timeout

İlk ve en ucuz savunma, her dış çağrıya açık ve kısa bir timeout vermektir. Varsayılan timeout’lar — çoğu HTTP istemcisinde 30 saniye veya daha fazla — production için kabul edilemez.

$response = Http::timeout(5)        // toplam süre
    ->connectTimeout(2)             // bağlantı kurma süresi
    ->get('https://sms-provider.example/send');

Laravel queue yazısındaki kural burada da geçerli: varsayılan 30 saniye değil, 5. Bir process’in bir bağımlılığı ne kadar süre bekleyeceğini şansa bırakmayın — bu sayı bir karar olmalı.

İkinci savunma: retry — ama dikkatli

Geçici hatalar için retry mantıklıdır, ama körlemesine retry zarar verir. Çöken bir servisi hemen yeniden denemek ona daha çok yük bindirir — buna retry storm denir; servisi tam ayağa kalkamadan tekrar devirir.

Retry yapıyorsanız iki şey şart: exponential backoff (her denemede artan bekleme) ve jitter (rastgele sapma — tüm client’lar aynı anda denemesin).

Http::retry(3, function (int $attempt) {
    // exponential backoff (200, 400, 800 ms) ve üstüne jitter
    return 200 * (2 ** ($attempt - 1)) + random_int(0, 100);
}, function ($exception) {
    return $exception instanceof ConnectionException;
})->timeout(5)->get($url);

Retry sayısını düşük tutun. Üç denemeden sonra hâlâ hata varsa, sorun geçici değildir; denemeye devam etmek yalnızca kendi process’inizi daha uzun bağlar.

Üçüncü savunma: circuit breaker

Timeout tek bir çağrıyı sınırlar; circuit breaker çağrı yapmayı bırakmaya karar verir. Mantığı bir elektrik sigortasından gelir ve üç durumu vardır:

Closed — her şey normal, çağrılar geçer. Hatalar sayılır.
Open — son N çağrının çoğu başarısız oldu; devre açılır. Artık dış servise hiç gidilmez, çağrı anında hata döner.
Half-open — bir süre sonra devre tek bir deneme çağrısına izin verir. Başarılıysa closed’a döner, değilse tekrar open.

Kazanç şu: dış servis hastayken siz onu beklemezsiniz. 5 saniyelik timeout bile process başına 5 saniyedir; open durumda bu süre 0’a iner. Fail-fast, yavaş-fail’den iyidir.

// Kavramsal akış — eşik, sayaç ve zamanlayıcıyı olgun bir pakete bırakın.
if ($breaker->isOpen('sms')) {
    return $this->queueForLater($message);   // devre açık: hiç deneme yok
}

try {
    $response = Http::timeout(5)->post($smsUrl, $payload);
    $breaker->recordSuccess('sms');
} catch (\Throwable $e) {
    $breaker->recordFailure('sms');          // eşik aşılırsa devre açılır
    return $this->queueForLater($message);
}

Bu mantığı sıfırdan yazmak yerine olgun bir paket kullanın — durum saymayı, eşiği ve zamanlayıcıyı doğru kurmak göründüğünden inceliklidir.

Fallback: devre açıkken ne yapılır

Circuit breaker’ın değeri, open durumda ne yaptığınızla ortaya çıkar. “Hata döndür” en zayıf seçenektir. Daha iyileri:

Kuyruğa al, sonra gönder. SMS hemen gitmek zorunda değilse, devre kapanınca işlenmek üzere kuyruğa bırakın.
Bayat ama geçerli veriyi sun. Bir döviz kuru servisi çökmüşse, son bilinen kuru göstermek hiç göstermemekten iyidir.
Özelliği zarifçe kıs. “Öneriler şu an yüklenemiyor” mesajı, koca sayfayı çökertmekten iyidir.

Hangi fallback’in doğru olduğu işe bağlıdır — ama “fallback yok” bir cevap değildir.

Ne zaman bu kadarına gerek yok?

Her dış çağrı circuit breaker istemez. Timeout her zaman şart. Retry, yalnızca işlem idempotent ise. Circuit breaker ise asıl olarak çağrı sık ve servis kullanıcı yolundayken değer katar — günde birkaç kez çağrılan bir entegrasyon için timeout ve makul bir retry çoğu zaman yeter.

Dış servis çökmesi bir “ihtimal” değil, bir “ne zaman” sorusudur. Onunla birlikte çökmek ise bir tasarım tercihidir — ve değiştirilebilir bir tercih.

Sisteminizi, en zayıf bağımlılığınız kadar kırılgan bırakmayın.

Serverless'a Geçiş Kararı: Cold-Start ve Vendor Lock-in

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 11 Jul 2026 00:00:00 GMT

Bir ekip yeni servisini “serverless first” kararıyla AWS Lambda üzerine kurdu. Oysa trafik sabit ve öngörülebilirdi — gün boyu aşağı yukarı aynı. Ay sonunda fatura, aynı işi yapan tek bir VPS’in birkaç katı çıktı; üstelik p95 latency de daha kötüydü.

Serverless yanlış bir teknoloji değil. Yanlış iş yüküne uygulanmış bir teknolojiydi.

Serverless ne satın alır

FaaS’ın (Function as a Service) gerçek getirileri var:

Sunucu yönetimi yok. Yama, ölçekleme, kapasite planı sağlayıcıda.
Sıfıra inen ölçek. İstek yoksa çalışan hiçbir şey yok, ödenen hiçbir şey yok.
Kullanım başına ödeme. Atıl kapasite için para ödemezsiniz.

Bu üçü, doğru iş yükünde gerçekten kazandırır. Mesele, o iş yükünü doğru teşhis etmek.

Cold-start’ın gerçek maliyeti

Bir fonksiyon bir süredir çağrılmadıysa, sağlayıcı onu sıfırdan ayağa kaldırır: runtime yüklenir, bağımlılıklar init olur, kod çalışır. Bu cold-start, çalışan bir process’e göre 100 ms’nin altından saniyelere kadar ek gecikmedir.

Önemli ayrım: cold-start, düşük trafikli bir endpoint için istisna değil kuraldır. Saatte birkaç çağrı alan bir fonksiyonda neredeyse her istek cold’dur. “Ölçeğe göre ödeme” cazip gelir, ama sıfıra yakın trafikte ödediğiniz şey, kullanıcının her seferinde gördüğü gecikmedir. Latency’ye duyarlı bir kullanıcı yolunda bu doğrudan bir UX maliyetidir.

Vendor lock-in

Lock-in yalnızca runtime değildir; asıl bağ etrafındaki yapıştırıcıdadır. Bir serverless uygulaması zamanla şunlara da bağlanır: sağlayıcının event kaynakları, kimlik/yetki modeli (IAM), yönetilen kuyruğu, API gateway’i, dağıtım araçları.

Tek bir fonksiyonu taşımak kolaydır. Ama gerçek bir sistemde “serverless’tan çıkmak” çoğu zaman bir taşıma değil, bir yeniden yazımdır. Bu, boring architecture yazısındaki innovation token mantığıyla doğrudan ilgili: tek bir karar gibi görünen şey, aslında geri alınması pahalı bir bağdır.

Hangi iş yükünde kazandırır

Serverless, yükün değişken ve seyrek olduğu yerde parlar:

Zamanlanmış işler — gecelik raporlar, cron benzeri görevler.
Webhook alıcıları — ne zaman, ne sıklıkta geleceği belirsiz.
Düşük hacimli iç araçlar — günde birkaç kez kullanılan paneller.
Ani patlamalı (bursty) batch işleri — saatte bir, kısa süreliğine yüksek paralellik.

Bu yüklerde sıfıra inen ölçek gerçek para tasarrufudur ve cold-start çoğu zaman önemsizdir — kimse bir gece raporunun 800 ms geç başlamasını dert etmez.

Hangi iş yükünde kaybettirir

Bunun tersi de net:

Sabit, sürekli trafik. Her zaman çalışan bir API’de “kullanım başına ödeme”, “her saniye ödeme”ye dönüşür — ve genelde sürekli çalışan bir sunucudan pahalıdır.
Latency’ye duyarlı yollar. Cold-start, kullanıcının beklediği bir istekte kabul edilemez.
Uzun süren işler. FaaS’ın çalışma süresi sınırları vardır; uzun işler ya bölünür ya da uymaz.

Bu profildeki bir iş yükü için sıkıcı bir VPS — tek VPS üzerinde çoklu proje yazısındaki kurulum gibi — hem daha ucuz hem daha öngörülebilirdir. Sabit yükün maliyeti, sabit bir sunucuyla eşleşir.

Laravel ve serverless

Laravel tarafında Laravel Vapor, uygulamayı Lambda üzerinde çalıştırmayı mümkün kılar ve iyi de çalışır. Ama çalışması, doğru karar olduğu anlamına gelmez: Vapor’la birlikte cold-start’ı ve AWS bağını da miras alırsınız.

Karar yine iş yüküdür. Trafiği patlamalı, seyrek ya da öngörülemez bir Laravel uygulaması için Vapor mantıklı. Sürekli ve latency’ye duyarlı bir uygulama için, klasik bir sunucu hâlâ daha sade ve ucuz cevaptır.

Karışık kullanın

Bu, ikili bir seçim değil. Sürekli yükü taşıyan sıkıcı bir sunucu + yalnızca seyrek/patlamalı işleri (webhook, gece raporu) serverless’a vermek çoğu zaman en dürüst dağılımdır. Her iş yükünü, kendi maliyet profiline ait olduğu yere koyun.

Serverless bir mimari modası değil, belirli bir iş yükü profili için bir araçtır. O profil sizde varsa kazandırır; yoksa cold-start ve lock-in olarak geri ödenir.

Önce yükünüzü ölçün; araç sonra gelir.

BFF Pattern: Mobil ve Web İçin Ayrı API Katmanı

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 04 Jul 2026 00:00:00 GMT

Bir mobil uygulamanın tek bir ana ekranı çizmek için API’ye dokuz ayrı istek attığını gördüm. API aslında web için tasarlanmıştı; mobil, web’in böldüğü veriyi parça parça toplayıp ekranda birleştiriyordu. Her açılış dokuz round-trip — üstelik mobil ağ koşullarında.

Bu, “tek API herkese yeter” varsayımının faturasıydı. BFF — Backend for Frontend — tam da bu faturayı kesmek için var.

BFF nedir

BFF, her istemci türü için ince ve ona özel bir API katmanıdır. Web’in kendi BFF’i, mobilin kendi BFF’i olur. Her biri arkadaki asıl servisleri/domain’i çağırır, ama yanıtı kendi istemcisinin ekranına göre şekillendirir.

Asıl iş mantığı BFF’te değildir. BFF sadece bir uyarlama katmanı: agregasyon yapar, gereksiz alanı kırpar, istemcinin tek ekranda ihtiyaç duyduğu şeyi tek yanıtta toplar.

Tek API’yi herkese uydurmanın gizli maliyeti

Tek bir genel API, zamanla iki istemciyi de tam memnun edemez:

Over-fetching. Mobil, 40 alanlı bir kullanıcı nesnesi indirir, 4’ünü kullanır. Geri kalanı boşa giden bant genişliği ve pil.
Chatty akış. Web’in normal bulduğu “önce listeyi çek, sonra her satır için detay çek” akışı, mobil ağda dokuz round-trip’e dönüşür.
Koşullu alanlar. Yanıt if mobile then ... else ... ile dallanmaya başlar. Tek endpoint, iki istemcinin gereksinimini aynı anda taşımaya çalışır ve ikisinde de orta karar bir iş çıkarır.
Versiyonlama düğümü. Web için yapılması gereken bir değişiklik, mobilin yayınlanmış sürümünü kırma riski taşır. İki istemci tek kontrata kilitlenir.

Bu maliyetler tek tek küçük görünür; toplamı bir mimari problemdir.

BFF ne zaman gerekli

BFF, istemcilerin ihtiyacı gerçekten ayrıştığında gerekçelidir:

Mobil ile web belirgin biçimde farklı ekranlara, farklı veri şekillerine ihtiyaç duyuyor.
Mobil ağ ve pil kısıtları, round-trip sayısını ve payload boyutunu birinci sınıf bir kaygı yapıyor.
İstemciler farklı tempoda yayınlanıyor — mobil sürümü mağaza onayına takılıyken web her gün deploy ediliyor; tek kontrat ikisini birbirine kilitliyor.

Bu farklar varsa, her istemciye kendi BFF’ini vermek, tek API’yi sürekli ikisine birden uydurmaya çalışmaktan ucuzdur.

BFF ne zaman gereksiz

Tek bir istemciniz varsa BFF, çözdüğünden fazla katman ekler — sadece fazladan bir sıçrama.

İki istemciniz var ama ikisi de neredeyse aynı veriyi aynı şekilde istiyorsa, yine gereksiz. BFF’i haklı çıkaran şey istemci sayısı değil, istemciler arasındaki farktır. Fark yoksa ayrı katman da olmamalı — bu, spekülatif genelliğin API katmanındaki hâli olur.

BFF mikroservis değildir

Sık karışan nokta: BFF eklemek sizi dağıtık mimariye sokmaz. BFF bir sunum/agregasyon katmanıdır, bir domain servisi değil. İçine iş kuralı koymak, kuralı istemci sayısı kadar kopyalamak demektir.

BFF’in mikroservisle tek ilişkisi şu: ikisi de “ayrı bir deployable’a değer mi?” sorusunu sorar. Cevap çoğu zaman “hayır” — mikroservise geçiş kararındaki ölçülmüş-sinyal eşiği burada da geçerli.

Hafif başlayın

“BFF” demek, ayrı bir sunucu kurmak demek zorunda değil. Aynı monolit içinde:

İstemci başına bir route namespace — routes/web-api.php, routes/mobile-api.php — her biri kendi controller’larıyla, kendi yanıt şekliyle.
Ya da tek bir GraphQL katmanı: her istemci ihtiyacı kadarını sorgular, over-fetching kendiliğinden çözülür.

Asıl fikir bir kutu değil, bir sınırdır: istemciye özel uyarlamayı tek bir yerde toplayın, domain’i ondan temiz tutun. Ayrı bir deployable’a ancak ölçülmüş bir sinyal zorladığında geçin.

BFF, “her istemci aynı API’yle idare etsin” inadının panzehiridir — ama yalnızca istemciler gerçekten ayrıştığında. Fark yoksa katman da olmamalı.

Katmanı ekleyen şey istemci sayısı değil, aralarındaki mesafedir.

Senkron mu, Asenkron mu? HTTP ile Kuyruk Arasındaki Sınır

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 27 Jun 2026 00:00:00 GMT

Bir kayıt formu sekiz saniye sürüyordu. İstek içinde sırayla şunlar oluyordu: kullanıcı kaydediliyor, hoş geldin e-postası gönderiliyor, bir PDF üretiliyor, bir CRM’e kayıt işleniyor. Kullanıcı bu sekiz saniye boyunca dönen bir spinner’a bakıyordu — oysa onu ilgilendiren tek şey, kaydının oluşup oluşmadığıydı.

Bir işi HTTP isteği içinde anında mı yapmalı, kuyruğa mı atmalı? Çizgi göründüğünden net.

Karar çizgisi: kullanıcı sonucu bekliyor mu?

Tek bir soru kararın çoğunu verir: kullanıcı bu işin sonucunu görmek zorunda mı?

Cevap “evet” ise iş senkron kalır — istek içinde, yanıt dönmeden biter.
Cevap “hayır” ise iş kuyruğa gider — istek “kabul edildi” der ve döner.

Yukarıdaki formda kullanıcı sadece “kaydım oluştu mu” cevabını bekliyor. E-posta, PDF, CRM — hiçbirinin sonucunu o ekranda görmesi gerekmiyor. Üçü de yanlış tarafta duruyordu.

Senkron kalması gerekenler

Kullanıcının sonucunu doğrudan gördüğü işler istek içinde kalır:

Girdi doğrulama — hata anında dönmeli.
Asıl kaynağın yaratılması — kullanıcı oluşturma, sipariş oluşturma.
Ödeme yetkilendirmesinin sonucu — kart geçti mi geçmedi mi, kullanıcı bunu o an bilmeli.
Kullanıcının bir sonraki adımda göreceği veri.

Bunları kuyruğa atmak, kullanıcıya “sonra bak” demektir — ve çoğu zaman kötü bir deneyimdir.

Kuyruğa gitmesi gerekenler

Kullanıcının sonucunu o an görmesi gerekmeyen her iş asenkrondur:

E-posta ve bildirim.
PDF ve rapor üretimi.
Webhook gönderimi.
Üçüncü parti senkronizasyonu — CRM, analitik, arama indeksi.
Görsel işleme, dışa aktarma.

Bunlar için doğru yanıt 202 Accepted’dir: “isteğini aldım, işliyorum.” Kullanıcı beklemez, sistem işi kendi temposunda yapar.

Çizgiyi yanıt süresi keskinleştirir

Her endpoint için bir p95 bütçeniz olmalı — diyelim 300 ms. Bir adım bu bütçeyi tek başına yiyorsa ve kullanıcı o adımın sonucunu görmek zorunda değilse, o adım kuyruğa gider.

Senkron zincir, en yavaş halkası kadar hızlıdır. PDF üretimi 4 saniye sürüyorsa, kullanıcı oluşturma da 4 saniye sürer — PDF’in yanıtla hiçbir ilgisi olmasa bile.

Hata toleransı: asıl ayrım

Asıl mesele hız değil, hatadır. Senkron ve asenkron, başarısızlığı bambaşka karşılar:

Senkron hata = kullanıcı bir hata ekranı görür. İş kaybolur.
Asenkron hata = job retry edilir, gerekirse DLQ’ya düşer, kuyruk sonra işler.

Buradan tek bir kural çıkar: kararsız bir üçüncü parti asla senkron yolda durmamalı. O CRM çağrısı istek içindeyse, CRM her çöktüğünde sizin kayıt formunuz da çöker. Kuyruğa alınmış bir çağrı ise, CRM döndüğünde retry kendiliğinden tamamlanır. Üçüncü partinin uptime’ı sizin uptime’ınız olmaktan çıkar.

202 ve durum sorgusu kalıbı

İş kuyruğa gidince kullanıcıya bir takip yolu bırakın:

POST /exports          → 202 Accepted  { "id": "exp_1a2b", "status": "processing" }
GET  /exports/exp_1a2b → 200 OK        { "status": "done", "url": "..." }

Kullanıcı sonucu beklemiyordur ama bazen merak eder. Bir durum endpoint’i ya da hazır olunca gönderilen bir bildirim, bu boşluğu kapatır.

Sınır nerede kalkar?

Bazı işler ikisinin arasındadır: kullanıcı sonucu görmek ister ama iş de yavaştır. Burada üçüncü bir yol var — işi senkron başlatın, ilk anlamlı sonucu hemen döndürün, gerisini kuyruğa devredin. Sipariş kaydını anında oluşturun (senkron), faturayı arkada üretin (asenkron).

Çizgiyi her iş için ayrı çizin; “her şey kuyruğa” da “her şey senkron” kadar yanlıştır.

Senkron mu asenkron mu sorusu bir performans sorusu değil, bir “kim bekliyor” sorusudur. Kullanıcının beklemediği hiçbir iş, onun isteğini bekletmemeli.

İsteği yalnızca, cevabını gerçekten istediği işle meşgul edin.

Transactional Outbox: Dual-Write, At-Least-Once ve İdempotent Tüketim

info@muhammetsafak.com.tr (Muhammet Şafak) — Mon, 22 Jun 2026 00:00:00 GMT

Belirti küçüktü: günde bir-iki fatura veritabanında duruyor ama consumer onları hiç görmüyordu. Kullanıcı “kestim” diyor, karşı tarafta hiçbir iz yok. Hep gece, hep bir deploy ya da network dalgalanması anında. Tabloyu netleştirince sebep ortaya çıktı — veritabanına INSERT ile kuyruğa publish iki ayrı sistemdi ve aralarında hiçbir garanti yoktu.

Bu yazı o boşluğu kapatan transactional outbox kalıbının, kapatınca açılan at-least-once tekrarının ve son olarak event’in içinden geçen kişisel veriyi alan seviyesinde şifrelemenin sistem tarafı. Karar zincirinin günlük tarafını muhammetsafak.com.tr’de ayrı yazdım; burada kalıbın production’da dayanıklı olması için verilmesi gereken kararları topluyorum.

Dual-write: bir transaction’ı iki sisteme yayamazsınız

Sorunun özü tek cümle: yerel veritabanı transaction’ınız RabbitMQ’yu kapsamaz. Klasik kod çoğu zaman çalıştığı için tehlikeli:

DB::transaction(function () use ($invoice) {
    $invoice->save();                 // 1) MySQL'e yaz
    $this->publishToRabbit($invoice); // 2) kuyruğa publish
});

İki ayrı arıza modu var:

save() başarılı, publish network hatasıyla düşer → DB’de fatura var, event yok. Kayıp event.
publish başarılı, ardından transaction başka sebeple rollback olur → event gitti, DB’de karşılığı yok. Hayalet event.

DB::transaction kurtarmaz, çünkü commit/rollback yalnızca MySQL tarafını sarar; broker o transaction’ın parçası değildir. İki sistemi tek atomik adımda tutmanın pratik yolu, yazmayı tek bir sisteme indirmek.

Outbox: önce tek sisteme yaz, sonra ayrı bir süreç yayımlasın

Kalıbın fikri sade: mesajı kuyruğa doğrudan basmak yerine, aynı transaction içinde bir outbox tablosuna satır olarak yaz. Fatura ile event aynı commit’te ya birlikte var olur ya da birlikte yok olur — dual-write tek write’a iner.

CREATE TABLE outbox (
    id            BINARY(16)   NOT NULL,        -- event id = idempotency anahtarı
    aggregate_id  BIGINT       NOT NULL,        -- ordering ve partition anahtarı
    topic         VARCHAR(120) NOT NULL,
    payload       JSON         NOT NULL,
    status        ENUM('pending','published') NOT NULL DEFAULT 'pending',
    created_at    DATETIME(6)  NOT NULL,
    published_at  DATETIME(6)  NULL,
    PRIMARY KEY (id),
    KEY idx_dispatch (status, created_at)        -- relay taraması bu indeksten gider
);

Yazma artık iş kodunun derdi değil:

DB::transaction(function () use ($invoice) {
    $invoice->save();
    Outbox::write('invoice.issued', $invoice->id, $this->payload($invoice));
});

Kuyruğa basmayı ayrı bir relay yapar: pending satırları okur, RabbitMQ’ya publish eder, başarınca published damgalar. Burada kritik gerçek şu: relay “publish ettim ama published damgasını vuramadan çöktüm” durumuna düşebilir. Yani outbox dual-write’ı çözerken size bedava bir garanti vermez — at-least-once verir. Mesaj kaybolmaz ama tekrar edebilir. Geri kalan her şey bu gerçeğin etrafına dizilir.

Relay’i nasıl beslersiniz: polling mi, CDC mi?

Relay pending satırları iki yoldan görebilir.

Polling — relay tabloyu periyodik tarar:

SELECT id, topic, payload
FROM outbox
WHERE status = 'pending'
ORDER BY created_at
LIMIT 100;

Basit, her veritabanında çalışır, operasyonel yükü düşük. Bedeli iki şey: tarama aralığı kadar gecikme (1 sn’lik poll = ~1 sn’lik kuyruk gecikmesi) ve boşta dönen sorgu. idx_dispatch indeksi olmadan bu tarama tablo büyüdükçe pahalılaşır; indeksle bile poll sıklığı ile DB yükü arasında pazarlık yaparsınız. Küçük-orta hacimde polling doğru cevap — gecikmeyi kabul edilebilir tutacak kadar sık, DB’yi yormayacak kadar seyrek (pratikte 200 ms–1 sn) ayarlayın.

CDC (change data capture) — relay tabloyu değil, veritabanının WAL/binlog’unu dinler (Debezium tipik araç). outbox’a düşen her INSERT neredeyse anında bir event’e döner; polling gecikmesi ve boşa tarama ortadan kalkar. Bedeli operasyonel: binlog’a erişim, bir connector süreci, ek bir hareketli parça. CDC’yi gecikme gerçekten önemliyse (saniye altı) ya da hacim polling’i zorluyorsa açarım; aksi halde polling’in sadeliğini bir avantaj sayarım.

Kural: gecikme bütçeniz ile operasyonel bütçeniz çatışır. CDC gecikmeyi satın alır, karşılığında bir altyapı parçası ödetir. Önce polling’le başlayın; CDC’ye ölçülmüş bir sebep çıkınca geçin.

Çoklu relay: `SKIP LOCKED` ile çakışmasız dağıtım

Tek relay bir bottleneck ve tek arıza noktasıdır. Birden çok relay aynı tabloyu tarayınca yeni bir risk doğar: ikisi aynı satırı kapıp aynı mesajı iki kez yayımlar. Naif çözüm tabloyu kilitlemektir — ki bu paralelliği öldürür.

Doğru araç SELECT ... FOR UPDATE SKIP LOCKED. Her relay bir batch satırı kilitleyerek claim eder; başka bir relay’in kilitlediği satırları sıraya girip beklemek yerine atlar:

BEGIN;
  SELECT id, topic, payload
  FROM outbox
  WHERE status = 'pending'
  ORDER BY created_at
  LIMIT 100
  FOR UPDATE SKIP LOCKED;     -- başka relay'in tuttuğu satırları atla, bekleme

  -- bu batch'i publish et, sonra:
  UPDATE outbox SET status = 'published', published_at = NOW(6)
  WHERE id IN (...);
COMMIT;

SKIP LOCKED olmadan relay’ler aynı satırlar için kuyruğa girer ve paralellik fiilen seri yürür. SKIP LOCKED ile her relay disjoint bir küme çeker, hepsi birden ilerler. PostgreSQL ve MySQL 8+ bunu destekler.

Bir incelik: publish ile UPDATE ... published arasında relay çökerse satır pending kalır ve yeniden yayımlanır. Bu kabul edilebilir — zaten at-least-once’tayız; çözüm tüketici tarafında, aşağıda. Tehlikeli olan tersidir: önce published damgalayıp sonra publish etmek. O zaman çökme kayıp event üretir ki tam kaçtığımız şey. Yani sıra değişmez: önce publish, sonra damga.

Ordering: neyi garanti edebilirsiniz, neyi edemezsiniz

“Event’ler yazıldığı sırada gelsin” sezgisel bir beklenti ama global ordering pahalı ve çoğu zaman gereksiz. Gerçekte ihtiyaç duyduğunuz şey aggregate başına sıradır: aynı faturanın created event’i updated’dan önce gelsin; iki farklı faturanın birbirine göre sırası kimsenin umurunda değil.

Bunu aggregate_id ile partition’layarak alırsınız: aynı aggregate_id’ye sahip event’ler aynı kuyruk partition’ına (ya da RabbitMQ’da consistent hash exchange ile aynı queue’ya) gider; o partition’ı tek consumer sırayla işler. Farklı aggregate’ler paralel akar.

outbox (created_at sırasıyla)
   │  hash(aggregate_id) % N
   ├── partition 0 ──► consumer-0   (aggregate A,D olayları — sıralı)
   ├── partition 1 ──► consumer-1   (aggregate B olayları   — sıralı)
   └── partition 2 ──► consumer-2   (aggregate C olayları   — sıralı)

İki şey ordering’i yine de bozar ve tasarımın bunlara hazır olması gerekir: çoklu relay SKIP LOCKED ile satırları farklı sırada yayımlayabilir ve at-least-once tekrarlar araya girebilir. Bu yüzden global sıraya bel bağlamak yerine, tüketiciyi sırasız ve tekrarlı event’e dayanıklı yazmak gerekir. Pratik kalkan: event’e monotonik bir version/sequence koyup tüketicide eskiyi (daha düşük versiyonu) düşürmek. Sıkı global ordering gerekiyorsa tek partition + tek consumer’a inersiniz — ki bu da throughput’u o tek consumer’a bağlar; çoğu sistem bu bedeli ödemek istemez.

At-least-once gelince: tüketici idempotent olmalı

Relay tekrar yayımlayabildiği için her event’in en az bir, bazen birden çok kez geleceğini varsaymak gerekir. Çözüm event’i tekil yapmaya çalışmak değil — tüketiciyi aynı event’i iki kez işlese de tek kez işlemiş gibi davranacak şekilde kurmak. İşlenen her event id’sini bir dedupe tablosuna yazıp işi aynı transaction içinde yapmak:

DB::transaction(function () use ($event) {
    $inserted = DB::table('processed_messages')->insertOrIgnore([
        'message_id'   => $event['id'],
        'processed_at' => now(),
    ]);

    if ($inserted === 0) {
        return; // tekrar gelmiş; hiçbir yan etki üretme
    }

    $this->applyBusinessEffect($event); // asıl iş — yalnızca bir kez
});

processed_messages.message_id üstündeki unique kısıt işin kalbi: ikinci kez gelen aynı id, insertOrIgnore ile sessizce elenir. İş etkisini aynı transaction’a almak şart — yoksa “işledim ama damgalamadan çöktüm” boşluğu açılır. Dedupe anahtarının nereden geldiği ve çökmeden sağ çıkan dedupe tasarımı başlı başına bir konu; oraya ayrı bir notta girdim.

Yan etki bir dış sistemse (e-fatura entegratörü, ödeme API’si) dedupe tek başına yetmez — çünkü yan etki transaction’ın dışındadır. Orada anahtarı dış servise taşımak gerekir: aynı id’yi entegratöre idempotency-key olarak geçmek, ya da göndermeden önce “bu zaten var mı?” diye sormak. Bu sınırı, numarayı dış çağrıdan önce mühürleyip recovery’yi bir lookup’a indiren JIT rezervasyon yazısında ayrıntılı işledim.

`processed_messages` sonsuza kadar büyüyemez

Dedupe tablosu her event için bir satır biriktirir; budanmazsa kendisi bir performans sorununa döner. Anahtar gözlem: bir event id’sini sonsuza kadar tutmanız gerekmez — yalnızca bir tekrarın gelebileceği pencere kadar tutmanız yeter. Relay retry’ları ve broker redelivery’leri saatler mertebesindedir, günler değil.

Pratikte sabit bir retention penceresi belirleyip (örneğin 7 gün — en uzun olası redelivery’nin rahatça üstünde) eskisini budarım:

DELETE FROM processed_messages
WHERE processed_at < NOW() - INTERVAL 7 DAY
LIMIT 10000;   -- tek seferde küçük batch'ler, replica lag'i ve kilidi kontrol altında

message_id UUID ise tablo ve indeks büyür; budama bunu sınırlı tutar. Pencereyi seçerken kuralı tersinden kurun: en uzun gecikmeli redelivery ne kadar sonra gelebilir? Cevabın güvenli üstünü retention yapın. Pencereyi çok kısa tutarsanız geç gelen bir tekrar dedupe’a takılmaz ve yan etki ikinci kez çalışır.

Exactly-once neden çoğu zaman bir yanılsama

Dağıtık sistemde “tam bir kez teslim” cazip ama uçtan uca garanti edilemez. Sebep aynı dual-write’ın broker sınırındaki hali: tüketici işi yaptı ama ack’i broker’a ulaştıramadan çöktü mü, broker mesajı yeniden teslim eder — çünkü ack görmemiştir. “İşledim” ile “işlediğimi bildirdim” iki ayrı adımdır ve aralarına çökme girebilir. Bu, iki general probleminin pratikteki yüzü.

Bu yüzden hedef exactly-once delivery değil, exactly-once effect. Bunu da iki ucuz garantiyi birleştirerek alırsınız:

at-least-once delivery  +  idempotent consumer  =  effectively-once

Yani teslimi tam bir kez yapmaya çalışmayı bırakıp tekrarı zararsız kılarsınız. “Exactly-once” pazarlayan sistemlerin altında çoğu zaman tam olarak bu vardır: at-least-once + bir dedupe katmanı. Garantiyi teslimde değil, etkide arayın.

Event’in içinden geçen kişisel veri: alan seviyesi şifreleme

Outbox oturunca yeni bir yüzey çıkar: event’lerin payload’ında müşteri adı, vergi numarası, adres gibi kişisel veri var ve bu payload artık kalıcı bir tabloda (outbox) duruyor, üstelik broker’dan geçiyor. Veriyi yerinde bırakırsam, GDPR/KVKK kapsamındaki alanları şifresiz biçimde birden çok yere kopyalamış olurum.

Bütün payload’ı şifrelemek istemedim — topic, aggregate_id, invoice_id gibi alanları relay yönlendirmesi ve gözlemlenebilirlik için açık görmem gerekiyordu. İhtiyaç alan seviyesi şifreleme: yalnızca hassas alanlar şifreli, gerisi açık. Hassas alanları şemada x-gdpr-sensitive ile işaretleyip serileştirmede yalnızca onları şifreledim:

$schema = [
    'invoice_id'    => ['x-gdpr-sensitive' => false],
    'customer_name' => ['x-gdpr-sensitive' => true],
    'tax_id'        => ['x-gdpr-sensitive' => true],
    'total'         => ['x-gdpr-sensitive' => false],
];

$payload = collect($raw)->map(fn ($value, $field) =>
    ($schema[$field]['x-gdpr-sensitive'] ?? false)
        ? Crypt::encryptString((string) $value)  // yalnızca hassas alan şifreli
        : $value
)->all();

Şemanın hassas alanı beyan etmesi tesadüf değil — bunu kuyruğun kenarında şema doğrulamasıyla birleştirince, “hangi alan kişisel veri ve doğru tipte mi?” sorularının ikisi de kenarda cevaplanır. Asıl mühendislik kararı şifrelemenin kendisinde değil, çevresindeki üç soruda:

Anahtar yönetimi ve rotasyon. Laravel Crypt, APP_KEY ile AES-256 kullanır. Tek bir anahtara bağlanırsanız rotasyon kabusa döner: eski anahtarla yazılmış outbox satırlarını yeni anahtar açamaz. Çözüm, şifreli değerin yanına anahtar versiyonu (key id) yazmak ve birden çok anahtarı aynı anda tanıyan bir keyring tutmak — yeni yazımlar güncel anahtarı kullanır, eski değerler kendi versiyonuyla açılır. Laravel’de config/app.php’deki key + previous_keys tam bunun içindir; decrypt sırasıyla eski anahtarları da dener. Rotasyonu bu yüzden veri taşımadan yapabilirsiniz.

Şifreli alanda arama. Crypt::encryptString her çağrıda farklı ciphertext üretir (rastgele IV), ki bu güvenlik için doğru ama WHERE tax_id = ? ile aramayı imkânsız kılar. Eşitlik araması gerekiyorsa blind index eklersiniz: aranabilir alanın deterministik bir HMAC’ini ayrı bir kolonda tutup onu sorgularsınız. Şifreli kolon gizliliği, blind index aranabilirliği taşır; ikisi ayrı kolondur çünkü iki ayrı işi vardır.

Anahtarı kaybetmek veriyi kaybetmektir. Alan şifrelemesi APP_KEY’i bir availability bağımlılığına çevirir: anahtar giderse şifreli alanlar kalıcı çöptür. Anahtar yedeği ve erişim kontrolü, şifrelemenin kendisi kadar tasarımın parçasıdır.

Ne zaman bu kalıbı kurmazsınız?

Outbox + idempotent tüketim + alan şifrelemesi ucuz değil: bir tablo, bir relay süreci (ya da CDC connector), bir dedupe tablosu ve onun budama işi, bir de anahtar yönetimi getirir. Karşılığında ne aldığınızı bilmiyorsanız ödemeyin. Şu durumlarda kurmuyorum:

Event kaybı tolere edilebiliyorsa. Yayımladığınız şey best-effort bir bildirimse (cache invalidation, “yeni içerik var” sinyali) ve bir-iki kayıp önemsizse, doğrudan publish yeterli. Outbox’ı kayıp önemli olduğu için kurarsınız.
Yazma ile yayım aynı sistemdeyse. Hedefiniz de aynı veritabanıysa (ayrı bir broker yoksa), dual-write zaten yok; outbox’a gerek kalmaz.
Hacim tek consumer’a sığıyorsa ve ordering kritikse. Düşük hacimde tek tüketicili bir kuyruk hem sırayı hem tekilliği basitçe verir; çoklu relay ve partition makinesini kurmak olmayan bir problemi çözmektir.

Kalıba ihtiyaç üç koşul birlikte doğunca başlar: event kaybı kabul edilemez, üretim/tüketim paralel ve veri ayrı bir sisteme (broker) gidiyor. Üçü birden yoksa daha sade bir çözüm vardır.

Üç parça tek bir disipline iner: veriyi tek bir sisteme yaz, tekrarı tüketicide bastır, hassas alanı yola çıkmadan mühürle. Outbox kuyruğa olan güveni, idempotent tüketim teslime olan güveni, alan şifrelemesi de payload’a olan güveni gereksiz kılar — her biri bir garantiyi koddan dışarı, tasarımın içine taşır.

Event-Driven Mimari: Ne Zaman Kurtarır, Ne Zaman Karmaşıklaştırır?

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 20 Jun 2026 00:00:00 GMT

“Sipariş oluşturulduğunda ne oluyor?” sorusuna bir ekipte kimsenin net cevap verememesini izledim. Kod tabanında OrderCreated event’ini sekiz ayrı listener dinliyordu; hangisinin hangi sırada, hangi koşulda çalıştığı tek bir yerden okunamıyordu. Akış kodda değil, kafalarda — hem de eksik — yaşıyordu.

Event-driven mimari bağı gevşetir. Bu yazı, gevşeyen başka bir şey daha olduğunu hatırlatmak için: nedensellik.

Event ne çözer

Bir event yayınlayan kod, onu kimin dinlediğini bilmez. OrderCreated yayınlanır; faturalama, bildirim ve analitik onu ayrı ayrı dinler. Sipariş kodu bu üçünden habersizdir.

Kazanç gerçek: yeni bir tüketici eklemek, üreticiye dokunmadan olur. Bağımsız geliştirme, bağımsız dağıtım, fan-out. Birbirini tanımayan parçalar.

Event neyi gizler

Aynı madalyonun öbür yüzü: bağ gevşedikçe akış görünmez olur.

Doğrudan bir method çağrısında akış kodun kendisidir — tanımına gidersiniz, devamını okursunuz. Event’te öyle değil. OrderCreated yayınlandığında ne olduğunu görmek için tüm listener’ları elle bulmanız gerekir. Compiler size yardım etmez: bir method çağrısının kontratını derleyici doğrular, bir event’in kontratını kimse doğrulamaz.

Modüler monolit yazısındaki cümle burada da geçerli — bir network kontratı gibi, bir event kontratı da derleyicinin kör noktasındadır.

Ödenmeden seçilmemeli: iki ön koşul

Event-driven mimariye geçmeden önce iki bedel peşin ödenir.

Schema disiplini. Event bir kontrattır. OrderCreated’in payload’ı değiştiğinde, onu dinleyen sekiz yerin haberi olmaz — ta ki production’da kırılana kadar. Event’ler versiyonlanmalı, alanlar geriye uyumlu eklenmeli, payload bir şema ile doğrulanmalı. Bu disiplin yoksa, gevşek bağ “sessiz kırılma” demektir.

İzlenebilirlik. Bir isteğin sistemden geçişini görebilmek için her event bir correlation ID taşımalı:

event(new OrderCreated(
    orderId: $order->id,
    correlationId: request()->header('X-Correlation-Id') ?? (string) Str::uuid(),
));

Bu ID log’lara ve sonraki event’lere taşınmazsa, çok-listener’lı bir akışta “bu iş neden çalıştı?” sorusunun cevabı yoktur. Tracing, event-driven’ın isteğe bağlı bir eklentisi değil, ön koşuludur.

Laravel’de: in-process event ≠ event-driven mimari

Laravel’in event()/listener mekanizması, senkron çalıştığında aslında düzenlenmiş bir method çağrısıdır — aynı process, aynı transaction, aynı stack trace. Bu güvenli ve izlenebilir; bunu rahatça kullanın.

Event-driven mimarinin getirdiği zorluklar, event bir sınırı geçtiğinde başlar: bir queue’ya, bir message broker’a, başka bir process’e. Listener’a ShouldQueue ekleyip event’i RabbitMQ’ya gönderdiğiniz an, schema ve tracing borcu devreye girer. İkisini birbirine karıştırmayın: in-process listener kullanmak sizi “event-driven mimariye” geçirmez.

Ne zaman event-driven’a geçilir

Event’i gerçekten bir sınırın ötesine taşımak şu durumlarda gerekçeli:

Gerçek bir fan-out var. Bir olayı, birbirini tanımaması gereken çok sayıda bağımsız tüketici dinliyor.
Tüketici asenkron olmalı. İş, üreticinin yanıtını bekletmemeli; “kabul edildi” yeterli.
Tüketiciler bağımsız ölçeklenmeli ya da dağıtılmalı. Bu da bizi mikroservis kararına götürür — aynı ölçülmüş-sinyal eşiği.

Bunlar yoksa, doğrudan bir service çağrısı hem daha okunur hem daha güvenlidir. Tek bir listener’ı olan bir event, sadece kılık değiştirmiş bir method çağrısıdır — üstelik izi sürülmesi daha zor olanı.

Event-driven mimari bağı gevşetir; bunu yaparken nedenselliği de gevşetir. Birincisini istiyorsanız, ikincisinin faturasını — schema ve tracing — peşin ödeyin.

Gevşek bağ bedava değildir; görünmez akışla ödenir.

Çok Kümeli GitOps’ta Sıfır Statik Yetki

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 20 Jun 2026 00:00:00 GMT

Bir GitOps controller’ı — Argo CD, Flux — bir kümede oturur ve birçoğunu reconcile eder. Diğerlerine ulaşmak için her uzak kube-apiserver’a kimlik doğrulaması yapması gerekir. Bunu yapmanın varsayılan yolu bir kimlik bilgisini saklamaktır: kontrol kümesinde bir Kubernetes Secret olarak tutulan bir bearer token, bir client sertifikası, bir kubeconfig. Argo CD’de bunlar argocd.argoproj.io/secret-type: cluster etiketli nesnelerdir.

Dur ve o Secret’ın ne olduğuna bak. O, genelde geniş yetkili, tüm filonuza nişan almış, tek bir yerde atıl duran, uzun ömürlü bir kimlik bilgisidir. Kendi kendine rotate olmaz. Yedeklerinizdedir. Kontrol kümenizde bir saldırganın bulabileceği en değerli tek şeydir, çünkü ona sahip olmak, eriştiği her kümeye sahip olmaktır. Boring architecture disiplininin tamamı, tutmak zorunda olmadığınız yükümlülükleri tutmamakla ilgilidir — ve saklanan filo geneli bir token, sırf kullanım anında taze ve kısa ömürlü bir tane basmak daha fazla iş gibi göründüğü için tuttuğunuz bir yükümlülüktür.

Bu yazı o fazladan işi, sırasıyla yapmakla ilgili. Hedef sıfır statik yetki: controller’ı bir uzak kümeye doğrulayan hiçbir uzun ömürlü kimlik bilgisi asla yazılı kalmaz. Controller’ın sunduğu kimlik talep anında basılır, yaklaşık bir saatte sona erer ve yalnızca bellekte yaşar. Mekanizma, kimlik modeli için SPIFFE ve onu basmak için SPIRE’dır.

Her şeyden önce: bu, bir elin parmaklarıyla sayabileceğiniz üç küme için bir araç değil. SPIRE, import ettiğiniz bir kütüphane değil, işlettiğiniz bir kontrol düzlemidir — tam da yavaş üstlenmeniz gereken türden bir yetenek; tıpkı bölünmeyi hak edene kadar modüler monolitin mikroservisi yendiği gibi. Ağırlığını ancak gerçekten bir filo işlettiğinizde hak eder — çok küme, çok ekip, çalınan bir Secret’ın geçemeyeceği bir denetim gereksinimi. Tek paylaşılan bir küme size yetiyorsa, en ucuz güvenli kimlik bilgisi, basmak için makineyi hiç kurmadığınız olandır. Geri kalanı, filoya gerçekten ulaştığınızı varsayar.

Tek kuralı baştan söyleyeyim

Mekanizmadan önce netleştireyim: bir küme sınırını geçen kimlik bilgisi kısa ömürlü olmalı ve asla saklanmamalı. Aşağıdaki her şey bu tek cümlenin hizmetinde. Sonunda kimlik doğrulama yolunda hâlâ bir yere diske yazılmış uzun ömürlü bir token kalıyorsa, uğruna geldiğiniz özelliği satın almadan karmaşıklık inşa etmişsinizdir — eksik bir index’ten kaçmak için read replica eklemekle aynı yanlış dönüş.

“Kısa ömürlü ve asla saklanmaz”ın burada kesin bir anlamı var. Kimlik, varsayılan ömrü bir saat olan bir X.509 sertifikası (ya da varsayılan ömrü beş dakika olan bir JWT); workload tarafından yerel bir socket’ten, sunacak kendine ait bir token’ı olmadan çekilir ve ömrünün yarısında otomatik rotate edilir. Yarın çalmaya değecek bir sır yok.

SPIFFE ve SPIRE gerçekte ne

SPIFFE bir spesifikasyon; SPIRE ise spesifikasyonun tarif ettiği şeyleri basan referans implementasyon. Dört isim tüm tasarımı taşıyor.

Bir SPIFFE ID bir URI’dir: spiffe://<trust-domain>/<path>, örneğin spiffe://prod.example.org/ns/argocd/sa/application-controller. Otorite kısmı trust domain’dir — tek bir mantıksal güven kökü, tek bir CA. Path workload’u tanımlar. Bir workload’un elinde tuttuğunu kanıtladığı isim budur.

Bir SVID (SPIFFE Verifiable Identity Document) ise kanıttır. İki biçim:

X.509-SVID — SPIFFE ID’si URI SAN’ında (CN’de değil, ki bu sonra önemli olacak) bulunan bir X.509 sertifikası. Onunla mTLS yaparsınız.
JWT-SVID — sub’ı SPIFFE ID, aud’unu hedef doğrulayıcıya scope’ladığın imzalı bir JWT. Onu bearer token olarak sunarsınız.

Asıl mesele ömürler. SPIRE’ın sunucu konfigürasyonunda varsayılanlar default_x509_svid_ttl: 1h ve default_jwt_svid_ttl: 5m’dir; bu SVID’ler, kendi ca_ttl’i varsayılan 24h olan bir CA tarafından imzalanır. Bunlar bilerek kısadır: sızdırılmış bir SVID bir saat içinde değersizleşir, ki tam da bu yüzden eskiden token sakladığınız yerde onu kullanmak güvenlidir.

“Asla saklanmaz”ı mümkün kılan şey, bir SPIRE agent’ı tarafından yerel bir Unix domain socket üzerinden sunulan Workload API’dir (belgelenmiş varsayılan /tmp/spire-agent/public/api.sock; çoğu kurulum onu /run/spire/sockets/... altında mount eder). Workload o socket’e bağlanır ve SVID’sini ister. Bunu yapmak için hiçbir kimlik bilgisi sunmaz. Agent, çağıran process’i kernel üzerinden inceleyerek tanır — PID’sini, oradan da container’ını, namespace’ini, service account’unu — ve bir dizi selector’a karşı workload attestation yapar. Kimlik, hangi sırrı tuttuğuyla değil, process’in doğrulanabilir biçimde ne olduğuyla kurulur. Saklanacak bir şeyin olmamasının tüm nedeni o tersine çevirme.

Altında SPIRE iki bileşen ve iki attestation’dır:

spire-server CA’yı tutar, SVID’leri imzalar ve registration entry’leri saklar. CA’sı varsayılan olarak self-signed, ya da bir UpstreamAuthority plugin’i aracılığıyla kurumsal PKI’nıza zincirlenmiş bir intermediate’tir — bir kez verdiğiniz ve birlikte yaşadığınız bir karar.
spire-agent her node’da çalışır. Önce node’u sunucuya kanıtlar — node attestation — k8s_psat gibi bir plugin’le; bu, projeli bir service-account token’ını Kubernetes TokenReview API’si üzerinden doğrular. Node’a yerleştirilmiş bir paylaşılan sır yoktur. Sonra her yerel process için, ona bir SVID vermeden önce workload attestation yapar.

Bir registration entry, bir SPIFFE ID’yi bir parent’a (node/agent) ve bir selector kümesine (namespace, service account, image) bağlayan sunucu tarafı kayıttır. Politika odur: bu workload, bu şekilde attest edilmiş, bu kimliği alır. Bu entry’lerin yaşam döngüsünü yönetmek gerçek bir iştir ve süregelen operasyonel maliyetin çoğu oradadır.

Federasyon: başka bir kümeden gelen bir SVID’ye güvenmek

Bir trust domain, bir güven köküdür. Çok kümeli bir filo genellikle birden fazla trust domain demektir — küme başına ya da bölge başına bir tane — ve artık A domain’indeki bir workload, B domain’inde basılmış bir SVID’yi doğrulayabilmek zorundadır. İşte bu federasyon’dur ve birimi trust bundle’dır: bir domain’in SVID’lerini doğrulamanızı sağlayan public CA sertifikaları ve JWT imzalama anahtarları (bir JWKS).

Her domain bir bundle endpoint ayağa kaldırır — güncel bundle’ını sunan bir URL, OIDC’nin jwks_uri’sinin SPIFFE karşılığı — ve her peer güncel kalmak için onu poll eder. İki profil var ve fark, tam da bootstrap sorusudur:

https_web — endpoint, public bir CA’dan bir Web-PKI sertifikasıyla cephelenir. Peer onu sıradan public güven deposuyla doğrular, yani bant dışında hiçbir başlangıç bundle’ının değiş tokuş edilmesine gerek yoktur. Güven mevcut Web PKI üzerinden bootstrap olur.
https_spiffe — endpoint kendi X.509-SVID’siyle kimlik doğrular. Onunla ilk kez konuşmak için peer’in o domain’in başlangıç bundle’ını zaten elinde tutması gerekir. Yani ilk bundle bant dışında gelmek zorundadır, ondan sonra ileriye dönük olarak en son çekilen bundle kullanılır.

Bir registration entry üzerinde federatesWith, bir workload’un kimlik doğrulamasına izin verilen yabancı trust domain’leri listeler; agent sonra o yabancı bundle’ları workload’a Workload API üzerinden teslim eder. Bundle’lar spiffe_refresh_hint aralığında (genelde beş dakika civarı) yenilenir ve yeni bir imzalama anahtarını, kullanmaya başlamadan birkaç yenileme döngüsü önce yayınlarsınız ki rotation indiğinde federe peer’ler onu çoktan öğrenmiş olsun.

“Sıfır statik yetki”nin dürüst şekline dikkat: federasyon, bootstrap güven kararının yerini değiştirir, onu silmez. https_spiffe ile bir başlangıç bundle’ını elle gönderirsiniz; https_web ile public CA sistemine yaslanırsınız. Her iki yolda da güven kökü hâlâ bir yerden gelir — ortadan kaldırdığınız şey, uzun ömürlü, geniş kapsamlı, küme başına kimlik bilgisidir; tek seferlik güven çıpası değil. Bu doğru takastır, ama olduğu gibi adlandırın.

apiserver’a bir SVID’yi kabul ettirmek

Niyetin Kubernetes API’siyle buluştuğu ve yanılmanın kolay olduğu yer burası. İki mekanizma var ve bugün yalnızca biri temiz.

JWT-SVID-olarak-OIDC yolu (işleyen). Kubernetes’e harici bir OIDC issuer’a güvenmesi söylenebilir. SPIRE, /.well-known/openid-configuration ve SPIRE’ın JWT-SVID imzalama anahtarlarıyla beslenen bir JWKS sunan bir OIDC Discovery Provider ile gelir. Uzak (spoke) kümenin apiserver’ını o provider’a bir OIDC issuer olarak yöneltirsiniz. Controller, yerel Workload API’sinden taze bir JWT-SVID çeker ve onu bir bearer token olarak sunar; apiserver onu SPIRE’ın JWKS’ine karşı doğrular ve bir subject’e map eder. Secret yok, saklanan token yok — istek başına yeni bir JWT, dakikalar içinde sona eren.

Bu bir düşünce deneyi değil. Red Hat, SPIFFE/SPIRE desteğini OpenShift 4.20’den itibaren Zero Trust Workload Identity Manager operatörü olarak sevk eder ve tam olarak bu bağlantıyı, OpenShift GitOps’un sevk ettiği bir ürün özelliği olarak değil, bir nasıl-yapılır rehberi olarak belgeler: Argo CD, execProviderConfig aracılığıyla bir client-go ExecCredential plugin’i (apiVersion: client.authentication.k8s.io/v1beta1) kullanır; bu plugin her çağrıda SPIFFE socket’ini (SPIFFE_ENDPOINT_SOCKET) okur, spoke apiserver’ın beklediği audience’la (SPIFFE_JWT_AUDIENCE) bir JWT-SVID ister ve onu teslim eder. Kimlik bilgisi kullanım anında imal edilir ve atılır.

X.509-SVID-ile-mTLS yolu (tuzak). İçgüdü düz mTLS yapmaktır: controller X.509-SVID’sini sunar, apiserver SPIFFE bundle’ına client CA olarak güvenir, bitti. Bitmedi. Kubernetes client-cert kimlik doğrulaması kullanıcı adını sertifikanın Subject CN’inden, grupları Subject O’sundan türetir — ve SPIFFE ID URI SAN’ında yaşar, ki apiserver client-cert kimlik doğrulaması onu okumaz. Bu yüzden ham bir SPIFFE X.509-SVID bir Kubernetes kullanıcısına map olmaz. mTLS kullanmak için apiserver’ın önüne bir proxy — Ghostunnel ya da Envoy — koyarsınız: SPIFFE mTLS’i terminate eder, URI-SAN SPIFFE ID’sini doğrular ve apiserver’ın anladığı bir kimlikle iletir. Ghostunnel kendi rotate olan SVID’leri için Workload API’yi doğrudan tüketir. Bu işler, ama her apiserver’ın önünde bir hareketli parçadır ve OIDC yolu onu hiç gerektirmez.

Olgunluk konusunda dürüst olun. Upstream Argo CD’nin native SPIFFE kimlik doğrulaması yoktur; jenerik ExecCredential plugin örüntüsüyle çalışır ve en olgun ürünleşme OpenShift’inkidir. Flux, SPIRE’ı deploy etmek için GitOps ile yönetilebilir ve OCI registry kimlik doğrulaması bir JWT-SVID tüketebilir, ama “Flux’u bir uzak kümeye kubeconfig yerine SPIFFE ile doğrula” şeklinde birinci sınıf bir özellik belgelenmemiştir — aynı OIDC/exec-credential/proxy tesisatının üzerinden gider. Native uzak küme SPIFFE kimlik doğrulamasını, etkinleştirdiğiniz bir kutu değil, monte ettiğiniz bir örüntü olarak görün.

Ne kırılır ve maliyeti ne

Mimari diyagramların atladığı kısım bu. Saklanan bir kimlik bilgisini kaldırdınız; karşılığında bir kimlik servisini kritik yolda sıkı bir bağımlılık hâline getirdiniz ve kısa ömürlü şeyler, uzun ömürlülerin kırılmadığı yerlerde kırılır.

SVID rotation artık bir erişilebilirlik bağımlılığı. SVID’ler kısadır — X.509 bir saat, JWT beş dakika — ve ömürlerinin yarısında rotate olur. Agent ya da Workload API ayakta değilse, ya da agent yenilemek için sunucuya ulaşamıyorsa, SVID sona erer ve kimlik doğrulama durur. SPIRE sunucusu her basım ve yenileme için kritik yoldadır. Agent’lar kimlik bilgilerini cache’ler ve kısa sunucu kesintilerine tolerans gösterir; agent’ın availability_target ayarı (ayarlanırsa ≥ 24h olmalı) onu erken rotate ettirerek nazik bir kesinti için pay biriktirir. Ama hata modu gerçek ve yeni: kimlik düzlemi ayakta değilse filo kimlik doğrulaması da ayakta değildir.
Saat kayması (clock skew) artık bir kesinti sınıfı. Beş dakikalık bir JWT affetmez. Bir controller ile bir spoke apiserver arasında birkaç dakikalık kayma, geçerli token’ları reddeder. Filo boyunca NTP disiplini, hijyen olmaktan çıkıp sıkı bir gereksinim olur.
Kararan bir federasyon bundle endpoint’i kümeler arası kimlik doğrulamasını kırar — sessizce, sonradan. Bir peer’in bundle endpoint’i yenileme penceresini aşacak kadar ulaşılamazsa ve o domain anahtarlarını rotate ederse, cache’lenmiş bundle’ınız bayatlar ve domain’ler arası SVID doğrulaması başarısız olur, her iki küme tek başına sağlıklı olsa bile. Hata, kesinti anında değil rotation anında ortaya çıkar, ki bu onu teşhis etmesi kötü kılar.
Kimlik düzlemi artık stateful, HA-kritik bir servis. HA’daki SPIRE sunucuları tek bir SQL datastore paylaşır; varsayılan SQLite tek-node’dur, yani production demek, tüm filonun kimlik doğrulayabilme yeteneğinin bağlı olduğu yüksek erişilebilir bir MySQL/PostgreSQL demektir. Çok küme için bir topoloji seçersiniz — nested SPIRE (bir root sunucunun downstream sunuculara intermediate basması, bir root kesintisinden sağ çıkması) ya da küme başına trust domain’ler arası federasyon — ve her biri kendi operasyonel yüzeyini ekler.
Operasyonel ağırlık baştan aşağı yeni bir kontrol düzlemi. Her kümede sunucu artı agent’lar; registration-entry yaşam döngüsü (workload başına selector’lar, deployment’larla senkron tutulan); upstream-CA kararı; bundle endpoint’ler ve federasyon ilişkileri; OIDC Discovery Provider; ve mTLS yolunda apiserver başına bir proxy. Cevap “bir kubeconfig sakla” olduğunda bunların hiçbiri yoktu.

Sıra neden önemli

Adımlar bir menü değil; bir dizidir ve onu atlamak, ekiplerin maliyeti faydası olmadan nasıl aldığıdır.

1. SPIRE’ı kur: sunucu + agent’lar, node attestation        (temel)
2. Controller’a Workload API üzerinden workload SVID’leri bas
3. Spoke apiserver’a SPIRE’a güvendir (önce OIDC yolu)
4. Kümeler boyunca trust domain’leri federe et
5. Saklanan kubeconfig Secret’larını sil                     (kazanç)

adım tüm mesele ve yalnızca 1–4 gerçekten işlediğinde güvenli. Yaygın hata, eski Secret’ı “yedek olarak” tutmaktır — bu da uzun ömürlü filo geneli kimlik bilgisinin hâlâ atıl, hâlâ yedeklerinizde, hâlâ saldırganın aldığı şey olması ve artık ayrıca SPIRE çalıştırıyor olmanız demektir. Kontrol düzleminin parasını ödediniz ve yükümlülüğü tuttunuz. Ya saklanan kimlik bilgisi yok olur ya da bunu yapmadınız; yarım kredi yoktur.

Tersi hata, sıra fayda verecek hâle gelmeden SPIRE’a uzanmaktır — Secret’ı gayet iyi olacak birkaç küme için federe bir kimlik düzlemi ayağa kaldırmak. Bu, güvenlik rozeti takmış ileride-lazım-olur karmaşıklığıdır: henüz sahip olmadığınız bir patlama yarıçapı için kurulmuş makine. Makineyi haklı çıkaran şey filo, denetim gereksinimi ve çalınan bir token’ın patlama yarıçapıdır. O çizginin altında, en ucuz güvenli kimlik bilgisi gerçekten de hiç basmak zorunda olmadığınız sıkıcı olanıdır.

Bu yaklaşımın gerçekten bittiği yer açık: statik bir küme başına kimlik bilgisinin kabul edilemez bir patlama yarıçapı olduğu kadar büyük bir filo, stateful, HA, kritik yolda bir kimlik servisini çalıştıracak ve saatlerini senkron tutacak operasyonel olgunlukla. Oraya varmış bir ekip o olgunluğun parasını zaten başka yerde öder — ve o noktada sıfır statik yetki bir süsleme değil, patlama yarıçapının baştan beri talep ettiği kimlik bilgisi modelidir. Daha önce değil.

İlgili: SPIFFE ve SPIRE belgeleri kimlik modelini ve sunucu/agent bileşenlerini tanımlar; SPIFFE Federation spec’i ise bu tasarımın dayandığı bundle-endpoint profillerini belirtir.

eBPF ile GPU FinOps

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 20 Jun 2026 00:00:00 GMT

Bir GPU node’u, bir raf dolusu CPU makinesinden saatte daha fazlaya mal olur ve finansın onun hakkında sorduğu soru, her şey hakkında sorduğu soruyla aynıdır: bunu kim kullandı ve ne kadar? CPU, bellek ve disk için bunu cevaplayabilirsiniz — cgroup’lar bunu process başına hesaplar, cAdvisor pod başına raporlar, Prometheus ekip başına toplar. GPU içinse çoğu kümede dürüst cevap, kimsenin bilmediğidir. Filodaki en pahalı kaynağın parasını ödüyorsunuz ve onun tek bir kuruşunu bile atfedemiyorsunuz.

Bu, doldurmayı unuttuğunuz bir araç boşluğu değil. Yapısaldır: GPU, yığınınızın geri kalanının dayandığı muhasebe düzleminin dışındadır. Bu yazı, bunun nedeni ve atfetmeyi geri kazanmak için eBPF kullanımı ile ilgili — ve eBPF’in ne görebildiği ve ne göremediğine dair sert bir çizgiyle birlikte, çünkü buradaki en pahalı hata, bir aracın fiziksel olarak cevaplayamadığı bir soruyu cevapladığına inanmaktır.

GPU mevcut metriklerinize neden görünmez

Üç ayrı körlük üst üste yığılır.

cgroup’lar GPU’yu hesaplamaz. Bir cgroup, CPU, bellek, block I/O ve PID’leri hesaplayan ve sınırlayan bir kernel yapısıdır. GPU bunların hiçbiri değil. Compute ve framebuffer (VRAM), NVIDIA kernel driver’ı ve userspace CUDA runtime’ı tarafından yönetilir ve cgroup hesaplamasına opaktır. Bir device cgroup controller’ı var, ama o yalnızca device node’larına (/dev/nvidia0 ve dostları) erişimi geçitler — izin ver ya da reddet. Tek bir saniye GPU zamanını ya da bir megabayt VRAM’i hesaplamaz. Yani size pod başına CPU ve bellek veren tüm cAdvisor → Prometheus boru hattının, kuruluş gereği, GPU hakkında söyleyecek hiçbir şeyi yoktur.

nvidia.com/gpu bir tahsis sayısıdır, bir kullanım sinyali değil. Kubernetes GPU’ları, onları kubelet’e extended resource nvidia.com/gpu olarak kaydeden NVIDIA device plugin’i üzerinden öğrenir. Pod’lar bunu bir integer olarak ister — bütün GPU’lar. Scheduler istenen sayıyı mevcut sayıyla eşler. Tahsis katmanının bildiği tek şey budur. Bir GPU istemek, bir GPU kullanmak değildir. Bir pod bütün bir cihazı tutabilir — ve bütün cihazın faturasını ödeyebilir — onu %3’te sürerken. Üzerinden chargeback yapabileceğiniz tahsis sayısı, tam da tüketim hakkında size hiçbir şey söylemeyen sayıdır.

nvidia-smi’nin kullanım sayısı bile size yalan söyler. nvidia-smi’ye uzanırsınız ve utilization.gpu alanı kurtuluş gibi görünür. Sandığınız şey değil. NVML onu şöyle tanımlar: örnekleme periyodu boyunca bir ya da daha fazla kernel’in çalıştığı zamanın yüzdesi. Zamansal varlığı — GPU hiç meşgul muydu — ölçer, ne kadarının meşgul olduğunu değil. Onlarca SM’den birini işgal eden tek thread’lik bir kernel %100’e yakın raporlayabilir. Microsoft, A100’ler üzerinde 8B parametreli bir modeli servis ederken bellek-bağımlı decode fazında %10’un altında compute kullanımı raporlamıştır — naif bir “kullanım” okuması o GPU’ları dolu sayacakken. utilization.gpu üzerinden chargeback yaparsanız, silikon neredeyse boştayken “meşgul” diyen bir sayı üzerinden faturalandırıyorsunuzdur.

Yani: tahsis katmanı kullanımı-değil-sayıyı bilir, cgroup’lar hiçbir şey bilmez ve tek kolay yüzde yanlış şeyi ölçer. Boşluk budur.

İki soru ve neden farklı araçlar gerektirdikleri

Herhangi bir araçtan önce iki soruyu ayırın, çünkü onları karıştırmak temel hatadır — bir aracın çözdüğü problemi eldeki problemle karıştırmakla aynı şekil.

Atfetme — GPU işini kim yaptı ve ne kadar? Bu FinOps sorusudur. Pod başına, ekip başına GPU aktivitesi hesabı gerektirir: hangi workload kernel başlattı, VRAM tahsis etti, veri taşıdı ve ne kadar süreyle. Chargeback bunun üzerinden koşar.
Verimlilik — silikon ne kadar iyi kullanıldı? SM’ler gerçekten doluydu mu, tensor core’lar aktif miydi, darboğaz bellek bant genişliği miydi? Bu performans sorusudur. Bir ekibin harcamasının haklı olup olmadığını söyler, ama kimin harcaması olduğunu söyleyemez.

Bunlar iki farklı ölçüm düzlemine eşlenir ve aşağıdaki her şeyi örgütleyen kural şu: eBPF atfetmeyi cevaplar; GPU’nun kendi sayaçları verimliliği cevaplar. Hiçbiri diğerinin yerine geçmez.

eBPF’in görebildiği: kontrol düzlemi

eBPF kernel’de çalışır ve kprobe’lara, uprobe’lara, tracepoint’lere ve syscall’lara takılır. Okunacak bir GPU-kullanımı tracepoint’i yok — ama GPU işinin talep edildiği iki yüzey var ve ikisi de kernel’den görünür:

Driver ioctl sınırı. Her parça GPU işi — kernel gönderimi, bellek tahsisi, senkronizasyon — sonunda /dev/nvidiactl’a ve /dev/nvidia0…N’e bir ioctl() olur. Driver’ın giriş noktalarındaki (nvidia_unlocked_ioctl, nvidia_open) bir kprobe o trafiği görür. (Kapalı driver tarihsel olarak yalnızca tek bir tracepoint, donanım hata olayları için nvidia:nvidia_dev_xid, sunar; geri kalan her şey kprobe’lanır.)
CUDA kütüphane sınırı. libcuda.so / libcudart.so üzerindeki bir uprobe API’nin kendisini izler: cuLaunchKernel, cuMemAlloc, cuMemcpyHtoD, cuStreamSynchronize ve dostları. Bir giriş uprobe’unu bir dönüş uretprobe’uyla eşlemek her çağrının süresini ölçer.

Bunun atfetme olmasının nedeni, eBPF’in her hook noktasında çağıran PID/TGID’yi ve cgroup’u native olarak okumasıdır — bpf_get_current_pid_tgid ve cgroup id tam orada. Bu size PID → cgroup → pod → namespace → ekip zincirini verir, uygulama değişikliği olmadan ve NVIDIA’nın işbirliği olmadan. Pod başına şunları alırsınız: kernel-başlatma sayıları, başlatma boyutları, VRAM tahsis boyutları, memcpy hacmi ve yönü, çağrı zamanlaması. Bu, tamamen sınırın kernel tarafından türetilen, gerçek ve savunulabilir bir chargeback sinyalidir.

Buradaki ekosistem genç ama gerçek. Primitifler bugün işliyor — CUDA kütüphanelerini uprobe’layan ve nvidia ioctl yolunu kprobe’layan çalışan yazılar ve eğitimler var ve bpftime eBPF mantığını GPU olaylarına bağlamayı keşfediyor. Tetragon (Cilium), Kubernetes pod kimliğiyle jenerik process_uprobe, process_kprobe ve ioctl izleme sevk eder, yani CUDA sembollerine ya da ioctl yoluna yöneltilebilir — ama bunun sevk edilen bir “GPU FinOps” özelliği değil, yazdığınız bir TracingPolicy olduğunu anlayın. Henüz baskın, anahtar-teslim bir eBPF chargeback ürünü yok. Size “tak-çalıştır eBPF GPU FinOps” satan biri, ekosistemin şu an ulaştığından öteye satıyordur.

eBPF’in göremediği: silikon

Dürüst limit bu ve bir sürümde düzeltilecek bir olgunluk problemi değil — verinin nerede yaşadığının fiziği.

eBPF kontrol düzlemini görür: API çağrıları, ioctl’lar, tahsis boyutları, başlatma sayıları ve izleyebildiğiniz yerde gönderim-tamamlanma zamanlaması. GPU’nun içini görmez. SM occupancy’sini, tensor-core kullanımını ya da erişilen bellek bant genişliğini okuyamaz, çünkü bunlar cihazda yaşayan ve yalnızca NVML / DCGM / CUPTI üzerinden açığa çıkan donanım performans sayaçlarıdır. eBPF’in onlara giden bir yolu yoktur. Bir pod’un on bin kernel başlattığını ve 40 GB VRAM tahsis ettiğini söyleyebilir; o kernel’lerin SM’leri doyurup doyurmadığını ya da onları %90 boş bırakıp bırakmadığını söyleyemez.

İkinci, daha incelikli bir limit var. eBPF’in takılabildiği ioctl sınırında bile, payload’lar büyük ölçüde opaktır. Driver’ın komut yapıları (NV_ESC_* Resource Manager API’si) karmaşık ve fiilen proprietary. Bir ioctl’ın olduğunu görebilirsiniz — komut numarasını, çağıran PID’yi, zamanlamayı — ama keyfi bir RM payload’unun semantik içeriğini decode etmek pratik dışı ve kırılgandır. İşin gerçeğini ve atfetmesini alırsınız, anlamının bedava bir okumasını değil.

Cazip bir kapıyı kapatan bir not: NVIDIA’nın açık kernel modülleri (open-gpu-kernel-modules, Turing ve sonrası) kernel arayüz katmanını açar — modül init’ini, ioctl giriş noktalarını, NV_ESC_* komut yüzeyini. Bu, neyi hook’layacağınızı anlamanıza gerçekten yardımcı olur. Ama GPU’nun beyni kapalı kalır: Turing+’ta yönetimin çoğu GPU üzerindeki GSP firmware’inde koşar ve o firmware — modüllerin ihtiyaç duyduğu user-mode driver bileşenleriyle birlikte — hâlâ kapalı olarak dağıtılır. Kernel modüllerini açmak, eBPF’e donanım performans sayaçlarını açmaz. Cihaz-içi limit değişmemiştir. Açık modüllerin eBPF’e SM occupancy okuttuğunu iddia eden biri, mevcut kanıtlara göre yanılıyordur.

Hâlâ ihtiyaç duyduğunuz userspace yolu: DCGM

eBPF silikonu göremediği için, cevabın verimlilik yarısı userspace’ten gelir ve standart araç, Prometheus için dcgm-exporter ile NVIDIA DCGM (Data Center GPU Manager)’dır. DCGM, GPU’nun donanım sayaçlarını driver üzerinden okur ve eBPF’in erişemediği alanları açığa çıkarır:

DCGM_FI_PROF_SM_ACTIVE — bir multiprocessor’da en az bir warp’ın aktif olduğu zamanın oranı, hepsinin ortalaması.
DCGM_FI_PROF_SM_OCCUPANCY — resident warp’ların desteklenen maksimuma oranı: gerçek occupancy.
DCGM_FI_PROF_PIPE_TENSOR_ACTIVE — tensor pipe’ın aktif olduğu döngülerin oranı.
DCGM_FI_PROF_DRAM_ACTIVE — bir bellek-bant-genişliği vekili.
DCGM_FI_DEV_FB_USED — gerçekten kullanımda olan framebuffer (VRAM).

Bunlar size bir ekibin pahalı tahsisinin ekmeğini kazanıp kazanmadığını söyleyen sayılardır. DCGM onları pod’lara, her GPU UUID’yi onu tutan pod’a eşleyen kubelet Pod Resources API’si (/var/lib/kubelet/pod-resources adresindeki bir gRPC servisi) üzerinden atfeder.

Ama DCGM’in atfetmesinin, tam da eBPF’in yerini hak ettiği yerde sert bir kenarı var: DCGM cihaz-seviyesi metrikler üretir, bu yüzden tek bir fiziksel GPU’yu paylaşan tüketicileri ayırt edemez. Time-slicing ya da MPS (Multi-Process Service) altında, bir GPU’yu paylaşan tüm pod’lar aynı, kopyalanmış cihaz-seviyesi değerleri alır — DCGM_FI_DEV_FB_USED dahil. NVIDIA’nın kendi exporter’ı, time-slicing etkinken metrikleri container’larla ilişkilendirmediğini belgeler; --kubernetes-virtual-gpus=true ile her paylaşan pod tüm fiziksel GPU’nun durumunu aynalar. MIG altında atfetme, keyfi pod’lara değil GPU-instance seviyesine kayar. Yani tam da paylaşılan-GPU durumunda — ki bu durum, bütün-GPU tahsisi para israf ettiği için var olur — DCGM size kimin ne tükettiğini söyleyemez. eBPF’in PID-seviyesi izlemesi söyleyebilir. İki araç, her birinin en zayıf olduğu dikişte birbirini tamamlar.

(En derin verimlilik profilleme için CUPTI, CUDA Profiling Tools Interface var; DCGM’in açığa çıkarmadığı sayaçları okuyabilir — ama Nsight Compute gibi metrik-replay profilleme kernel’leri birden çok kez yeniden çalıştırır ve ağır overhead taşır. Bu bir profilleme-oturumu aracıdır, her zaman açık tenant başına telemetri değil. DCGM düşük-overhead’li, örnekleme-bazlı sürekli yoldur; CUPTI ağır, derin olandır.)

Kernel-vs-userspace takası, açıkça

Düzlem	Araç	Görür	Göremez
Kernel (kontrol)	eBPF	PID→pod atfetme, başlatma sayıları, tahsis boyutları, memcpy hacmi, çağrı zamanlaması — time-slicing altında pod başına dahil	cihaz-içi SM/tensor occupancy, bellek bant genişliği, ioctl payload içleri
Userspace (cihaz)	DCGM	gerçek SM occupancy, tensor aktivitesi, DRAM aktivitesi, kullanılan VRAM — donanım sayaçlarından	paylaşılan GPU altında (time-slicing/MPS) pod başına atfetme: tüm paylaşanlar aynı değerleri alır

eBPF düşük-overhead’lidir, uygulama değişikliği gerektirmez, vendor işbirliği gerektirmez ve PID/cgroup üzerinden native atfeder — kim ve ne kadar için doğru araç odur. DCGM silikonu okur — ne kadar iyi için doğru araç odur. Maliyetler de dürüst: uprobe’lar gerçek overhead taşır ve CUDA sembolleri versiyonludur (cuMemAlloc@CUDA_11.0 vs @CUDA_12.0), yani probe’lar dinamik sembol çözümü gerektirir ve driver yükseltmeleri boyunca kırılır; CUDA API çağrıları saniyede on binden fazla atabilir, yani handler’lar ucuz kalmalı yoksa ölçtükleri workload’u yavaşlatırlar. DCGM kendi örnekleme overhead’i olan userspace polling’dir ve yalnızca belirli sayaç gruplarının birlikte okunabildiği bir donanım kısıtı taşır.

İkisine de neden, hangi sırayla ihtiyacınız var

Yanlış dönüş, bir aracı seçip ona diğer aracın sorusunu sormaktır — ekipleri DCGM’in cihaz-seviyesi sayıları üzerinden faturalandırıp bir GPU’yu paylaşan herkesi sessizce fazla yüklemek, ya da eBPF’in başlatma sayılarına verimlilik vekili olarak güvenip meşgul görünen bir workload’un iyi kullanıldığı sonucuna varmak. Gerçekten işleyen sıra:

1. eBPF: GPU işini pod/ekibe atfet           (kim, ne kadar — fatura)
2. DCGM: cihaz-içi verimliliği ölç           (ne kadar iyi — haklı mıydı)
3. Onları pod kimliğinde birleştir            (ekibin harcaması VE verimliliği)

Atfetme önce, çünkü finansın gerçekten sorduğu soru o ve mevcut yığınınızın hiç cevaplayamadığı o. Verimlilik sonra, çünkü faturayı bir karara dönüştürür — pahalı bir tahsisi %4 occupancy’de tutan bir ekip, artık görebileceğiniz bir ileride-lazım-olur kapasite vergisi ödüyordur; oysa önceden GPU, kimsenin açamadığı düz bir kalemdi. Pod kimliğinde birleşince, nihayet her diğer kaynak için sahip olduğunuz şeye sahip olursunuz: atfedilmiş harcama, üzerinde harekete geçecek verimlilik bağlamıyla. İki düzlem gerektirmesinin nedeni, görünmez olmasının nedeniyle aynıdır — silikon muhasebe düzleminde hiç yaşamadı ve tek bir probe bile sınırı kat etmiyor.

İlgili: DCGM exporter belgeleri pod-atfetme yolunu, DCGM özellik genel bakışı ise profilleme alanlarını tanımlar; bunun yaslandığı eBPF primitifleri ebpf.io ve Tetragon’da belgelenmiştir.

Dead-Letter Kuyruğunu Daha Kötü Yapmadan Replay Etmek

info@muhammetsafak.com.tr (Muhammet Şafak) — Fri, 19 Jun 2026 00:00:00 GMT

Aşağı akıştaki bir API yirmi dakika düştü. Dört bin mesaj retry’larını tüketip dead-letter kuyruğuna düştü. API artık geri geldi, mesajlar hâlâ geçerli ve bariz hamle onları geldikleri yere geri koymak. Broker konsoluna uzanıp orders.dlq’dan orders’a mesaj taşımaya başlıyorsun.

Orada dur. Bir dead-letter kuyruğu bir bekleme alanıdır, mezarlık değil — ama mesajları oradan çıkarmak yüklü bir operasyondur ve “sadece geri taşı”, atlatılmış bir kesintiyi ikinci bir olaya çevirmenin yoludur.

Naif bir replay’in işi daha kötü yapmasının iki yolu

Kuyruğu yeniden zehirler. DLQ’n nadiren sadece kesintinin kurbanlarını tutar. Aralarına gerçek bir nedenle ölen mesajlar karışmıştır — bozuk bir payload, bir bug, yönlendirilemeyen bir URN — ve onlar replay ettiğin an yine başarısız olacak. Replay’in her şeyi körlemesine geri kürelerse, gerçekten bozuk mesajlar başarısız olur, tekrar DLQ’ya düşer, sen onları yine replay edersin. CPU yiyen, logları dolduran ve aslında başarılı olacak mesajları gömen bir döngü.

Yan etkileri yeniden tetikler. Üç denemeden sonra dead-letter’a düşen bir mesaj her seferinde kısmen çalışmış olabilir. Kart çekildi ama onay e-postası patladı; mesaj başarısız oldu, retry oldu, dead-letter’a düştü. Onu naifçe replay et, handler baştan sona yine çalışır — şimdi nihayet gönderdiği e-postanın üstüne ikinci bir tahsilat. Kuyruk bir mesaj taşıdı; müşterin iki kez faturalandı.

İki tuzak da replay’i “byte’ları geri taşı” sanmaktan gelir. Öyle değil. “Bir mesajı sıfırla ve güvenle yeniden işle” — ve bu kelimelerin her biri bir emniyet kilidi.

Sıfırla, ama kimliği koru

Dead-letter’a düşmüş bir mesaj, nasıl öldüğünü anlatan ek bir blok taşır — neden, orijinal kuyruk, deneme sayısı. Onu replay etmek için sıfırlaman gerekir: o bloğu düşür ve deneme sayacını sıfıra geri al ki taze bir retry bütçesi alsın, anında yeniden tükenmesin.

Ama reset, yeni ile aynı şey değil. Mesajı tanımlayan her şeyi koru — id’sini, payload’ını ve hepsinden önemlisi korelasyon kimliğini (trace_id). İki nedenle:

İzleyemediğin replay edilmiş bir mesaj operasyonel bir kör nokta. trace_id’yi koru, replay orijinal hatayla aynı trace’te görünsün.
Korunan mesaj id’si, replay’i retry’a güvenli kılan şey. Tüketicilerin idempotent ise — mesaj id’si üzerinden dedupe ediyorsa — zaten yarı başarılı olmuş bir mesajı replay etmek dedupe tarafından yakalanır, yeniden çalıştırılmaz. Idempotency ve replay ortaktır: idempotency, bir kuyruğu nefesini tutmadan replay etmeni sağlayan şeydir.

Önce production’a doğrultma

Reset edilmiş ve idempotent olsa bile, bir replay canlı bir sisteme yazmadır. Güveni aşamalarla kazan:

Dry-run. DLQ’yu oku ve neyin replay edileceğini raporla — sayılar, hedefler, nedenler — ve her mesajı dokunmadan geri koy. Tek el atmadan patlama yarıçapını öğrenirsin.
Sandbox. Replay’i, tüketicilerinin dış yan etkileri stub’lanmış production dışı bir kuyruğa yönlendir. Mesajlar gerçek handler mantığından akar; kimse faturalandırılmaz. “İyi” mesajların gerçekten iyi olduğunu burada öğrenirsin.
Sonra production, ilk ikisi sıkıcı hâle geldiğinde.

Sıra, herhangi bir tek adımdan daha önemli. Mesajlar “iyi görünüyor” diye doğrudan production’a replay etmek, ilk paragraftaki broker konsolunda onları taşıyan güvenin aynısıdır.

Select et; saçma

Kesintinin kurbanları ortak bir imza taşır — bir zaman penceresi, bir hata reason’ı, bir URN. O kümeyi replay et, tüm kuyruğu değil. Reason’a göre seçmek, “timeout’tan ölen 4.000’i replay et” ile “4.000 timeout artı yine geri gelecek 30 gerçekten zehirli mesajı replay et” arasındaki farktır. Zehirli mesajlar replay etme sorunun değil; düzeltme sorunun ve onları görebildiğin DLQ’da kalmalılar.

Resetleyemeyeceğin yan etki

İşte dürüst olmak gerekirse zor kısım. Reset envelope’u temizler; idempotency birebir replay’leri dedupe eder; sandbox sen test ederken production’ı korur. Ama production’a kasıtlı bir replay — gerçek olanı, aslında istediğin — handler’ı çalıştırır ve handler ne yapıyorsa onu yapar: tahsilat çeker, e-posta atar, üçüncü tarafı çağırır. Idempotency bir kopyayı durdurur; amaçlanan yeniden işlemenin yan etkileriyle birlikte işini yapmasını durdurmaz.

Temiz çözüm, bir handler’a replay çalıştırdığını bildirip zaten olmuş dış etkileri atlamasını sağlamak — veritabanı yazmasını yeniden yap, ama e-postayı yeniden gönderme. İş şu ki o bayrağı nereye koyacaksın: donmuş bir mesaj envelope’unda ekleyecek yer yok. Cevap, dağıtık izlemenin aynı kısıt için kullandığıyla aynı — onu bant dışında taşı, mesajın yanında giden ve runtime’ın handler’a sunduğu bir transport header olarak. Handler’ın kontrol edebileceği, yalnızca replay edilmiş mesajlarda set edilen, normal yolda hiçbir maliyeti olmayan bir replay-bypass işareti. En zahmetli parça ve en sona bırakılacak doğru parça — reset, dry-run, sandbox ve select replay’i rutin olacak kadar güvenli hâle getirdikten sonra.

Bir dead-letter kuyruğu, çeyreğin en kötü gününde sistemindeki en faydalı şeydir. Onu replay etmeyi olduğu şey gibi ele al — canlı trafiği yeniden işlemek — ve faydalı kalır. Byte taşımak gibi ele al ve DLQ’nun devam filmi gelir.

İlgili: BabelQueue redrive-and-replay spec’i bu sıfırla-ve-yeniden-işle şeklini standartlaştırır; dlq-redrive örneği ise onun çalıştırılabilir bir hâlidir.

Polyglot Bir Kuyrukta Dağıtık İzleme

info@muhammetsafak.com.tr (Muhammet Şafak) — Fri, 19 Jun 2026 00:00:00 GMT

Bir mesaj bir PHP servisi tarafından üretiliyor, bir kuyruğa düşüyor, bir Go worker’ı onu tüketiyor, o da bir devam mesajı yayınlıyor ve onu bir Python servisi işliyor. Dört hop, üç dil, aralarda bir ya da daha fazla broker. O akış yavaşladığında ya da on binde bir mesaj öldüğünde soru hep aynı: bu mesaj gerçekte nereye gitti ve her adımda ne oldu?

Çoğu polyglot kuyruk sistemi için dürüst cevap: kimse bilmiyor. Log’larda bir korelasyon kimliğin var — üç dilde de loglamayı hatırladıysan — ve farklı host’lardaki üç log akışında grep çekecek sabrın var. Sahip olmadığın şey bir resim. “PHP’de 2ms’de üretildi → Redis’te 40ms bekledi → Go’da 210ms’de işlendi, iki kez retry oldu, DLQ’landı”yı tek bir bağlı şey olarak göremiyorsun.

İşte o resim bir dağıtık trace’tir ve onu çizmenin standart yolu OpenTelemetry’dir. Bu yazı, onu tel formatı donmuş ve çekirdekleri sıfır bağımlılık taşıyan bir mesaj standardına eklemekle ilgili — bu iki kısıt, bir arada, en bariz yaklaşımı yasadışı kılıp daha ilginç olanı zorunlu hâle getiriyor.

Tek kuralı baştan söyleyeyim

Her şeyden önce şunu netleştireyim: envelope’a bir alan ekleme.

Bir mesaj veriyolu boyunca dağıtık izleme istediğinde ilk içgüdü, bir W3C traceparent taşımaktır — bir trace id’yi, bir span id’yi ve flag’leri kodlayan o standart 55 karakterlik string. HTTP tam olarak bunu bir header’da yapar. Bu içgüdü HTTP için doğru, burada yanlış; çünkü envelope donmuş bir kontrattır. Her dildeki her SDK, byte-bazında aynı şekli yayınlar: job, trace_id, data, meta, attempts. Bir traceparent alanı eklemek — opsiyonel olsa bile — o şekli değiştirir, bu da bir versiyon artışı, bu da altı dil implementasyonu ve her broker bağlaması boyunca koordine edilen bir tel değişikliği demektir. Opsiyonel gözlemlenebilirlik olması gereken bir özellik için bu saçma bir bedel.

Yani kural, kısıtın kendisi: izlemeyi tele dokunmadan çöz. Aşağıdaki her şey bunu ciddiye almaktan çıkıyor.

Kimsenin kullanmadığı içgörü

Envelope’un sana bedavaya verdiği şey şu. trace_id alanı bir korelasyon kimliği — üretim anında basılan ve her hop boyunca değişmeden taşınan bir UUID. Zaten tel üzerinde, zaten taşınıyor, zaten tüm akışı birbirine bağlayan o tek değer.

Şimdi OpenTelemetry’nin bir trace’i birbirine bağlamak için kullandığı şeye bak: bir TraceID. Spesifikasyonda bir TraceID tam olarak 16 byte’tır.

Bir UUID tam olarak 16 byte’tır.

Bütün hüner bu. UUID bir trace_id, bir OTel TraceID’ye birebir eşlenir — tireleri at, 32 hex karakteri 16 byte’lık kimlik olarak oku, bitti. (UUID olmayan bir trace_id — diyelim BabelQueue dışı bir üreticiden geldi — SHA-256 ile deterministik olarak 16 byte’a hash’lenir.) Dolayısıyla aynı trace_id’yi paylaşan her hop, aynı OTel TraceID’yi türetir — bir anlaşma protokolü ve yeni bir alan olmadan. Zaten taşıdığın korelasyon kimliği dağıtık trace’in ta kendisidir.

Tasarım da kendini yazıyor:

Tüketici tarafında handler’ı sar. Çalışmadan önce process <urn> adında bir span başlat, ama o span’i mesajın trace_id’sinden türetilen trace’in içine zorla. Onu messaging convention’larıyla etiketle — messaging.system, messaging.destination.name, messaging.message.id ve trace_id’nin kendisine eşitlenen messaging.message.conversation_id — handler’ı çalıştır ve herhangi bir exception’ı span’in hata durumu olarak kaydet. Runtime’ın retry / dead-letter davranışı el değmeden kalır; span sadece onu gözlemler.
Üretici tarafında aynası. Bir publish <urn> span’i aç, onun trace id’sini al, tekrar bir UUID’ye biçimlendir ve envelope’u kurarken mesajın trace_id’sine bas. Aşağı akıştaki tüketici, TraceID’sini aynı trace_id’den türeterek aynı trace’e iner.

Jaeger, Tempo, Honeycomb ya da Datadog için bir TracerProvider bağla; akış üç dil boyunca tek bir şelale olarak belirir, her hop’un zamanlamasıyla ve retry/hata işaretleriyle. Bağlama, hiçbir şey değişmez — tamamen opt-in.

Mekanizma ve bir hayalet

Net olmaya değer bir ayrıntı var, çünkü tasarımın hem zekice hem de sınırlı olduğu yer orası.

OpenTelemetry’de bir span’i belirli bir trace’in içinde başlatmak için ona bir uzak ebeveyn (remote parent) verirsin — istediğin trace id’yi taşıyan bir span context. Ama bir span context yalnızca hem bir trace id hem de bir span id’si varsa geçerlidir. Trace id’miz var (trace_id’den); span id’miz yok, çünkü bilinçle bir tane taşımadık. Bu yüzden trace_id’yi hash’leyerek deterministik, sıfır-olmayan bir span id sentezliyoruz. Ebeveyn geçerli, tüketici span’i doğru trace’e iniyor — ama ebeveyni hiç var olmamış bir span’i gösteriyor. Bir hayalet.

Yukarıdaki tasarımın dürüst sınırı bu ve açıkça söylemeye değer. Hop’lar-arası span’lerin hepsi tek bir trace’i paylaşır — bir mesajın hayatının her adımını bir arada, zamanlanmış, hatalar işaretlenmiş görebilirsin. Tek başına bunun vermediği şey, hop’lar arasında birebir ebeveyn-çocuk bağı: tüketicinin span’i üreticinin span’inin çocuğu olarak bağlanmaz, çünkü üreticinin gerçek span id’si tel boyunca hiç taşınmadı. Tek bir process içinde hiyerarşi doğrudur; kuyruğun ötesinde tek trace altında düzdür.

Gerçek hop’lar-arası ebeveyn-çocuğu geri almak, bir span id taşımak demek, o da bir traceparent demek — ve envelope donmuş olduğundan, o traceparent bant dışında, her broker bağlamasının trace_id için zaten kullandığı yuvanın yanında bir transport header olarak gitmek zorunda: SQS, Pulsar ve Kafka’da bir bq-trace-id alanı; RabbitMQ, Azure Service Bus ve ActiveMQ Artemis’te native correlation-id yuvası; hiç per-message metadata taşımayan Redis’te ise envelope gövdesinin kendisinden başka bir şey yok. Bu gerçek bir özellik, ama farklı ölçekte bir iş: her SDK’daki her transport bağlamasına dokunur. Yani bilinçli bir ikinci faz olarak bırakıldı — ve o faz bu yazıdan iki gün sonra kapandı: ADR-0028 ile traceparent transport-header taşıması 21 Haziran 2026’da altı SDK çekirdeğinin hepsine v0.2 olarak indi. Teslim edilen bir traceparent artık tüketici span’ini üreticinin span’inin gerçek çocuğuna yükseltiyor; taşınamadığı yerde — kalan boşluk PHP’nin Kafka, Pulsar ve STOMP üreticileri — yukarıda anlatılan v0.1 trace_id korelasyonuna temiz biçimde düşüyor. Sıralamanın kendisi zaten meseleydi: yukarıdaki birinci-faz tasarımı korelasyonu, hop başına zamanlamayı ve hata/retry görünürlüğünü — yani %90’ı — sıfır tel değişikliğiyle ve dil başına birkaç yüz satırla teslim eder ve v0.2’nin üzerine oturduğu zemin olarak kalır. %90’ı önce, son %10’u daha büyük bir işin ardına bırakarak göndermek doğru sıraydı — tıpkı pahalı ölçekleme adımlarından önce ucuzları yaptığın gibi.

Tek semantik, altı paketleme deyimi

Çekirdeğin bağımlılıksız kalması kısıtının bir sonucu var: OpenTelemetry kodu, OTel API’sini import etmek zorunda olduğu her yerde çekirdekte yaşayamaz. Bu yüzden altı dilin beşinde çekirdeğin yanında yaşar, yalnızca opt-in ettiğinde erişilir — ve “çekirdeğin yanında, opsiyonel” her ekosistemde farklı yazılır. (.NET istisna; nedenine birazdan geliyoruz.) Altısında da semantik aynı; paketleme her dilin karakterini gösterdiği yer:

Go — ayrı bir modül (babelqueue-go/otel, kendi go.mod’u), tıpkı transport alt-modülleri gibi. Çekirdek modül OTel bağımlılığını hiç görmez.
Python — bir [otel] extra’sı. pip install babelqueue[otel], opentelemetry-api’yi getirir; modül onu import eder, yani yalnızca sen istediğinde import edilebilir. Buradaki bir TraceID byte değil, 128-bit bir int’tir — aynı değer, farklı biçim.
Node — bir subpath export, @babelqueue/core/otel, @opentelemetry/api ile opsiyonel bir peer dependency olarak. Kritik nokta: izleme kodu paket kökünden yeniden export edilmez: edilseydi, @babelqueue/core’u import etmek OTel import’unu erkenden yükler ve peer’i kurmayan herkes için kırılırdı. Subpath, ana girişi gerçekten bağımlılıksız tutar.
Java — opentelemetry-api üzerinde optional bir Maven bağımlılığı. Optional bağımlılıklar transitive değildir, yani izleme sınıflarına hiç dokunmayan bir tüketici OTel’i classpath’ine hiç çekmez.
.NET — ilginç olanı. .NET’te idiomatik izleme primitifi System.Diagnostics.ActivitySource’tur, base class library içinde yaşar — ve OpenTelemetry .NET’in üzerine kurulduğu tam olarak odur. Yani .NET modülünün hiçbir bağımlılığı yok — çekirdeğin yanında değil, içinde durabilmesinin sebebi de bu (BabelQueue.Core / Telemetry): Activity nesneleri yayınlar, tüketicinin OTel boru hattı onları AddSource("BabelQueue") çağırarak toplar. Çekirdek, bağımlılığı izole ederek değil, bağımlılığa sahip olmayarak sıfır-dep kalır.
PHP — bir Composer suggest artı bir dev gereksinimi, mevcut opsiyonel yardımcıları aynalayarak. İzleme namespace’i orada; open-telemetry/api yalnızca kullanırsan gerekir.

Altı deyim, hepsinde tutulan tek kural: gözlemlenebilirliği kullanmak tüketicinin yaptığı bir seçimdir, asla çekirdeğin kestiği bir vergi değil.

Gerçekte ne elde ediyorsun

Mekanizmayı bir kenara bırak, kazanç tarif etmesi küçük, sahip olması büyük. Mevcut izleme backend’inde, eskiden üç log samanlığında bir iğne olan bir mesaj tek bir şelaleye dönüşür: onu hangi servis üretti, broker’da ne kadar bekledi, her tüketici ne kadar sürdü, retry oldu mu, DLQ’landı mı — zaten ortalıkta dolaştırdıkları bir UUID dışında hiçbir konuda anlaşmasını gerektirmediğin diller ve broker’lar boyunca.

Ve bunun tel üzerindeki maliyeti sıfır. İzleme var olmadan önce giden envelope ile onunla birlikte giden envelope byte-byte aynı. Trace baştan beri trace_id’nin içinde saklıydı; bütün iş, bir UUID ile bir TraceID’nin aynı on altı byte olduğunu fark etmekti.

İlgili: BabelQueue observability spec’i bu tasarımı bir standart olarak yazıya döker; onu uygulayan SDK’lar — PHP, Go, Python, Node, Java ve .NET boyunca — BabelQueue ekosisteminde yaşar.

Şemayı Kuyruğun Kenarında Doğrulamak

info@muhammetsafak.com.tr (Muhammet Şafak) — Thu, 18 Jun 2026 00:00:00 GMT

Bir worker production’da KeyError fırlatmaya başladı. Sebep kendi kodu değildi — upstream bir servis, olayın payload’ından bir alanı düşüren bir değişiklik shiplemişti ve kuyruk bozuk mesajı tek kelime etmeden taşımıştı. Hata, kötü mesaj değildi. Hata, onu sınırda kontrol eden hiçbir şeyin olmamasıydı.

Kuyruk byte taşır, tip değil

Bir request body tipli bir handler’a çarpar; yanlış şekildeyse framework onu kapıda reddeder. Kuyruk sana bunun hiçbirini vermez. Payload opak JSON’dur — broker byte taşır ve içine asla bakmaz. Üretici ne koyduysa, tüketici onu alır, geçerli olsun olmasın. Tek bir servisin içinde sahip olduğun tip güvenliği, veri telden geçtiği an buharlaşır.

Yani bir mesajın şekli hakkında bir garanti istiyorsan, onu kendin eklemelisin — kenarda, verinin girdiği ve çıktığı yerde.

Verinin girdiği ve çıktığı yerde doğrula

İki kenar var ve farklı hataları yakalar:

Üretici tarafında, yayınlamadan önce — birincil olan. Payload’ı üretirken doğrula. Geçersiz veri kuyruğa hiç girmez, hata senkron olarak gerçekten hatası olan serviste ortaya çıkar ve bir kez yakalanır — mesaj her tüketiciye yayılmadan önce. Başarısız olmanın ucuz yeri burası.
Tüketici tarafında, alırken — güvenlik ağı. Tüketirken yine doğrula. Bu, üretici tarafının yakalayamayacağını yakalar: kontrol etmediğin üreticilerden gelen mesajlar — başka bir takım, eski bir deploy edilmiş sürüm, elle hazırlanmış bir replay. Burada doğrulamayı geçemeyen mesaj zehirli bir mesajdır; handler’ı döngüde çökertmek yerine onu bir dead-letter kuyruğuna yönlendir.

Bilmeye değer bir incelik: çoğu kuyruk runtime’ında “anında reddet” kancası yoktur, yani tüketici tarafı bir ret genelde dead-letter’a gitmeden önce retry eder — ve geçersiz veri retry’de geçerli olmaz. Bu boşa iştir; üretici tarafının değerli olmasının sebebi tam olarak budur. Tüketici tarafı emniyet kemeridir, direksiyon değil.

Şema envelope’la değil, mesajla yaşar

Doğruladığın şey, mesaj türü başına bir şemadır — olayın kimliğiyle anahtarlanır, taşıma envelope’una cıvatalanmaz. Onu bağımsız sürümlenen bir registry’de tut; tüketicileri kırmadan dikkatle evrimleştirdiğin aynı şema, runtime’da zorladığın şema olur. Tek sözleşme, hem değişim-anında (bu düzenleme birini kırıyor mu?) hem runtime’da (bu mesaj ona uyuyor mu?) kontrol edilir.

Bu, bir mükerrer teslimatı no-op yapmanın yapısal kuzeni: ikisi de ne geldiğini kontrol etmediğini kabul eder ve garantiyi göndericiye güvenmek yerine kendi sınırına koyar.

Ne zaman buna değmez

Tek bir servisin iç kuyruğu — tek üretici, tek tüketici, birlikte deploy — buna ihtiyaç duymaz. Tip sistemi zaten iki ucu da kapsar; kenar doğrulaması törendir. İkinci, bağımsız deploy edilen bir üretici ya da tüketici var olduğu an değmeye başlar — farklı bir takım, farklı bir dil, farklı bir sürüm temposu. O an aynı zamanda tipsiz payload’ın sessizce en kırılgan sözleşmen hâline geldiği andır.

İlgili: BabelQueue schema-validation spec’i URN-başına şemayı ve nerede zorlandığını tanımlar; babelqueue-registry o şemaları tutar — kontrolü çalıştıran ise onun bqschema aracıdır.

Mimari Kararların Çürüyor Çünkü Onları Hiçbir Şey Çalıştırmıyor

info@muhammetsafak.com.tr (Muhammet Şafak) — Thu, 18 Jun 2026 00:00:00 GMT

Yeni bir mühendis bana domain katmanının neden database paketini import ettiğini sordu — “bir ADR (mimari karar kaydı) import etmemesi gerektiğini söylemiyor mu?” Söylüyordu. İki yıldır söylüyordu. Ve o iki yılın çoğunda, bir yerlerde, kural sessizce çiğnenmişti: şurada bir helper, burada bir “sadece bu seferlik” import, her biri kendi pull request’inde makul. Karar wiki’de hâlâ doğruydu. Kodda aylar önce doğru olmaktan çıkmıştı ve kimse fark etmedi, çünkü onu izleyen hiçbir şey yoktu.

Yazıp da zorlayamadığın bir karar bir kural değildir. İyi formatlanmış bir dilektir.

Diyagram ile kod, küçük ve makul adımlarla ayrışır

Kimse mimariyi çiğnemeye karar vermez. Her seferinde savunulabilir bir commit’le aşınır: async yolu yazmak daha yavaş olduğu için eklenen senkron bir çağrı, ihtiyacın olan fonksiyon öbür tarafta olduğu için bir sınırı geçen bir import. Her diff tek başına iyi görünür. Hasar birikimli ve yapısaldır — tek bir değişiklik ölçeğinde görünmez, ancak geri çekilip katmanlamanın yok olduğunu bulunca belli olur.

Bu tam da bir insan review’ının çalıştığı ölçek ve tam da kaçırdığı ölçek. Review en iyi bir değişikliğin mimarisinde işler, ama bir reviewer tek bir PR görür, sınırı nihayet eriten bininci import’u değil. Bir insandan her commit’te tüm bağımlılık grafiğini kafasında tutmasını isteyemezsin. Wiki sayfası da tutamaz; o nesirdir ve nesir bir build’i patlatmaz.

Kısıtı çalıştırılabilir yap

Çözüm daha iyi yazılmış bir ADR değil. Kararın zorlanabilir kısmını nesirden çıkarıp çalışan bir şeye taşımak.

“Domain altyapıya bağımlı olmamalı” özünde bir görüş değildir — import grafiği üzerinde bir kısıttır: domain/ altındaki dosyalar db/’yi import edemez. Bu, bir aracın her commit’te deterministik olarak değerlendirebileceği ve çiğnendiğinde build’i kırabileceği bir kural — çiğneyen import main’e ulaşmadan, iki yıl sonra değil. Yakalama maliyeti, “bir şey nihayet kırılınca yapılan bir arkeoloji seansı”ndan “onu sokan PR’daki kırmızı bir kontrol”e iner.

Bu, bir şemayı değiştirmek yerine sürümlemenin aynı hamlesi: herkesin üzerinde anlaştığı bir kural, mekanik bir şey çizgiyi tutana dek hiçbir şey etmez — çünkü insan disiplini, her katkıcının her commit’ine ölçeklenmez.

Dokümanda ne kalır, ne kod olur

Bu ADR’yi öldürmez — onu ikiye böler. Bir mimari kararın iki parçası vardır: gerekçe (hexagonal katmanlamayı niye seçtik, neyi feda ettik, ne zaman yeniden gözden geçiririz) ve kısıt (domain hiçbir şey import etmez; API, DB’yle yalnızca bir repository üzerinden konuşur). Gerekçe nesre aittir — bir aracın tutamayacağı, bir insanın ihtiyaç duyduğu bağlam. Kısıt ise koda aittir, kontrol edilebileceği yere.

Neden’i yazmaya devam et. Ne’yi zorlamak için nesre güvenmeyi bırak.

Bu ne zaman önemsizleşir?

Tüm sistemin iki katman ve tek bir masanın etrafına sığan bir takımsa, sınırlar herkesin kafasında yaşar ve onlar için bir CI kapısı törendir. Üçüncü bir katkıcı katıldığı ya da kod tabanı tek bir kişinin tutabileceğini aştığı an, zorlanmayan sınır zaten aşınıyordur — sadece yeni mühendis domain’in neden database’i import ettiğini sorana dek görmezsin.

Bir mimari, karar verdiğin şey değildir; kodunun şu an yaptığı şeydir. Büyüyen bir kod tabanıyla temasta hayatta kalan tek kararlar, bir şeyin her commit’te kontrol ettikleridir. Gerekçeyi insanlar için yaz — ve sınırı, onu zorlamaktan asla yorulmayan bir makineye devret.

İlgili: archlint, tam da bunun için yazdığım araç — katman kurallarını okuyup bir ihlalde build’i kıran, deterministik bir import-sınır linter’ı (Go, TypeScript ve Python), paketlenmiş bir CI Action’ıyla.

Idempotency: Aynı Mesaj İki Kez Geldiğinde

info@muhammetsafak.com.tr (Muhammet Şafak) — Wed, 17 Jun 2026 00:00:00 GMT

Bir müşteri tek sipariş için iki kez ücretlendirildi. Hiçbir şey bilerek iki kez çalışmadı: ödeme worker’ı kartı çekti, sonra mesajı ack’leyemeden çöktü — broker da sözünü tutup mesajı yeniden teslim etti.

Hata, mükerrer teslimat değildi. Mükerrer teslimat için inşa edilmemiş handler’dı.

At-least-once bir söz, bir arıza değil

Neredeyse her queue — ve yeniden denenen her HTTP çağrısı — at-least-once’tır. Bir handler aynı mesajı birden çok kez görebilir: bir çökme, bir release, bir redelivery ya da timeout’a düşüp yeniden deneyen bir istemci sonrası. Ağ üzerinde exactly-once, broker’ın ucuza veremeyeceği bir koordinasyon olmadan pratik değil; bu yüzden çok az broker onu vaat eder — vaat edenler de (Google Cloud Pub/Sub gibi) dar koşullara sıkıştırır: tek bölge, yalnızca pull aboneliği.

Bu, problemi yeniden çerçeveler. Redelivery, yok edilecek bir başarısızlık değil; etrafında tasarım yapılacak bir garanti. (Queue’nun başarısız bir job’u kaybetmek yerine yeniden denerken yaptığı pazarlığın aynısı.)

Idempotent demek “iki kez = bir kez” demek

Bir operasyon, defalarca uygulandığında etkisi bir kez uygulanmışla aynıysa idempotent’tir — f(f(x)) = f(x).

“Sipariş durumunu paid yap” idempotent’tir.
“Bakiyeyi 10 artır” değildir — iki kez +20 eder.
“Karşılama e-postasını gönder” değildir — iki kez iki e-posta eder.

Bütün iş, ikinci tür operasyonu birinciye çevirmek.

Idempotency anahtarı göndericiden gelir

Bu operasyon için kararlı bir kimliğe ihtiyacın var ve bunu gönderici belirlemeli, alıcı değil:

Bir queue mesajı için bu, üreticinin ürettiği mesaj-başına id’dir — mesaj başına bir id, trace/correlation id’den ayrı (o, birçok mesajı kapsar).
Bir HTTP yazımı için bu, istemcinin ürettiği Idempotency-Key başlığı’dır — Stripe modeli.

İki kural anahtarı dürüst tutar:

Yalnızca payload’dan türetme. Meşru biçimde birbirinin aynı iki istek — aynı müşterinin aynı ürünü iki kez alması — çakışır ve ikincisi sessizce düşürülür.
Anahtarı alıcıya ürettirme. Alıcı, bir retry’ı yepyeni bir çağrıdan ayıramaz; “bu, daha önce denediğim aynı operasyon” bilgisi yalnızca göndericide vardır.

Dedupe: zaten yaptığını hatırla

Handler, işten önce tek bir kontrol yapar: bu anahtar işlendi mi? Evetse atla ve ack’le. Hayırsa işi yap, sonra anahtarı kaydet. Tüm desen bu — ağırlık, kaydın nerede durduğunda.

İş ile kayıt arasındaki çökme

Zor kısım, işi yapmakla anahtarı kaydetmek arasındaki boşluk. İki şekil var ve doğrusu yan etkiye bağlı:

Seen-set — başarıdan sonra kaydet. Handler döndükten sonra anahtarı Redis’e ya da bir tabloya yaz. Ucuz ve geniş çapta uygulanabilir. Pencere: yan etkiden sonra ama kayıttan önce çökersen, bir redelivery yeniden işler. Yan etkinin kendisi idempotent’se sorun değil — bir UPSERT, bir “set to paid”.
Transactional — işle birlikte kaydet. Idempotency kaydını, iş değişikliğiyle aynı veritabanı transaction’ında yaz. Pencere yok: anahtar ve etki birlikte commit olur ya da birlikte geri alınır. Bedeli: etki, senin kontrol ettiğin bir DB yazımı olmalı ve anahtar deposu aynı veritabanı olmalı — ayrı bir Redis değil. Kendi kontrolündeki bir etki için mükerrer işlemeyi gerçekten bitiren budur.

Yani yan etki senin yerine seçer: sahip olduğun bir satır → transactional; transaction’ına dahil edemeyeceğin üçüncü-taraf bir çağrı (e-posta, bir çekim) → seen-set ve kendi anahtarını onun Idempotency-Key’i olarak ileterek downstream’i de idempotent yap.

Eşzamanlı mükerrerlere kontrol değil, constraint lazım

Aynı anahtarın, ikisi de kaydetmeden yarışan iki teslimatı bir “önce kontrol et sonra yaz” dizisinden sıyrılır — o dizi atomik değil. Anahtar kolonundaki bir unique constraint atomiktir: ikinci insert, yakalayıp “zaten işlendi” diye ele aldığın bir conflict’e dönüşür. Bu, sıralı numara üretiminde bir race’in açtığı gap’lerin aynı şekli — benzersizlik gerçekte uygulamada değil, veritabanında zorlanır.

Buna ne zaman hiç ihtiyacın yok?

Handler zaten idempotent’se — kararlı bir id ile anahtarlanmış saf bir UPSERT, bir “alanı şu değere ayarla” — hiçbir şeye ihtiyacın olmayabilir. Anahtar + dedupe’a, operasyonun idempotent olmayan bir yan etkisi (para, e-posta, dış bir POST) ya da birikimi (increment, append) olduğunda uzan. Karmaşıklığı yalnızca ikinci çalıştırmanın gerçekten zarar verdiği yere harca.

At-least-once, düzelteceğin kısım değil; kabul ettiğin kısım. Handler’ı, ikinci teslimat bir no-op olacak şekilde kur; o zaman redelivery bir olay olmaktan çıkar ve olduğu şeye döner — broker’ın sözünü tutması.

İlgili: BabelQueue idempotency spec’i anahtarın nereden geldiğini ve dedupe’un nasıl davrandığını sabitler; idempotency-payments örneği ise tam da bu çift-çekim vakasının çalıştırılabilir hâlidir.

AI Darboğazı Kaldırmadı, Yerini Değiştirdi

info@muhammetsafak.com.tr (Muhammet Şafak) — Wed, 17 Jun 2026 00:00:00 GMT

İzlediğim bir ekip, ajanlara yaslanınca kabaca iki kat kod üretmeye başladı. Altı hafta sonra daha yavaş teslim ediyorlardı. Pull-request kuyruğu üçe katlanmış, CI yeşilden çok kırmızıydı ve iki olayın kökü kimsenin gerçekten okumadığı değişikliklere çıkıyordu. Çıktı arttı; throughput düştü.

Bunda gizem yok. Hattın tek bir istasyonunu hızlandırıp buna zafer dediler.

Tek istasyonu hızlandırıp buna throughput diyemezsin

Bir teslimat hattı bir istasyon dizisidir: yaz → review → entegre et → doğrula → release. Throughput’u en yavaş istasyon belirler, en hızlısı değil. Yazmayı 3× hızlandırırsın ama review ve doğrulama yerinde kalırsa throughput’u üçe katlamış olmazsın — kısıtı yalnızca bir istasyon aşağı taşımış ve onun önünde bir work-in-progress yığını büyütmüş olursun.

O yığın bedavaya gelmez. Merge conflict’e yaşlanan okunmamış PR’lar, yarı entegre branch’ler, kimsenin yeşil tutamayacağı kadar hızlı büyüyen bir test süiti. Kod ucuzlayınca darboğaz yok olmadı. Yer değiştirdi — ve görülmesi zorlaştı, çünkü artık “kod yazmak” gibi değil “beklemek” gibi görünüyor.

DORA’nın bunun için zaten bir kelimesi var: büyüteç

2024 ve 2025 DORA (DevOps Research and Assessment) raporlarının verisi aynı noktaya öbür taraftan iniyor: AI bir büyüteç, kısayol değil. Güçlü teslimat pratiklerine sahip ekipler ondan daha çok verim alıyor; sahip olmayanlar disfonksiyonlarını daha hızlı sevk ediyor. Her iki rapor da AI benimsemesinin istikrar düşüşüyle ilişkilendiğini gördü — çünkü gerçek kısıt her zaman süreçti, klavyede yazmak değil.

Büyüteç, ne verirsen onu yükseltir. Temiz bir sinyal verirsen daha yüksek ve net olur; gürültü verirsen yalnızca daha yüksek gürültü. Hangisi olduğuna AI karar vermiyor. Aşağı tarafın veriyor.

Darboğaz gerçekte nereye gitti?

Hep pahalı olan ama şimdi boğulan kısımlara taşındı:

Review. Üretim, insanların gerçek dikkat verebileceğinden hızlı PR çıkarıyor — böylece review bir lastik damgaya bozuluyor; okunmamış değişikliklerin production’a ulaşma yolu tam da budur.
Doğrulama. Test yazmak artık neredeyse bedava; süitler tam da bu yüzden, güveni inşa etmekten hızlı aşındıran kararsız, zamana bağımlı testlerle doluyor.
Entegrasyon. Daha çok elin daha hızlı yazdığı daha çok kod; daha çok coupling ve aynı mesajın ya da isteğin iki kez gelip durumu bozmasının daha çok yolu demek.

Bunların hiçbiri bir klavye problemi değil. Hepsi, hızlı yazmanın faturası.

Kalıcı yatırım, sıkıcı olan aşağı taraf

Yani bu çağdaki mühendislik üstünlüğü “AI yazdı” değil. Yazılana güvenmenin maliyetini, yeni darboğaz boğulmayacak kadar düşük tutmak. O iş cazip değil ve AI’ın geri verdiği zamanı harcayacağım yer orası:

Doğrulamayı deterministik yap; ki yeşil bir kontrol bir anlam taşısın ve review ona yaslanabilsin.
Entegrasyonu idempotent ve dayanıklı yap; ki daha hızlı, daha dağınık değişiklik redelivery’yi bir çift çekime çevirmesin.
Review’ı virgül değil mimari hakkında yap — mekanik kısmı araçlara bırak ki ölçekleyemediğin insan dikkati gerçekten önemli kararlara gitsin.
Bariz hatayı, üç istasyon sonra CI’da yüz kat pahalıya değil, commit sınırında yakala.

Bu, “vibe coding ilk sürümün maliyetini düşürür, yanılmanın maliyetini değil” dersinin aynısı — tek bir değişiklik yerine tüm hattın seviyesinde okunmuş hâli.

Bu ne zaman geçerli değil?

Gerçek kısıtın hâlâ üretimse — sahici bir greenfield, tek kişilik bir prototip, henüz koruyacak bir aşağı tarafı olmayan bir spike — o zaman hızlı git ve var olmayan bir sistem için süreç kurma. Kayma ancak dürüst tutulacak bir şey olduğunda ısırır: bir ekip, bir review kuyruğu, başkalarının bağımlı olduğu bir production.

Hangi dünyada olduğunu bilmek, asıl muhakeme. İki kat kod üreten çoğu ekip artık birincisinde değil.

AI mühendisliği ucuzlatmadı; bir kısmını ucuzlattı. Disiplin, kazandığın zamanı tam da darboğaza dönüşen kısma harcamak — zaten yığılmakta olandan daha fazlasını üretmeye geri dökmek değil.

Kararsız Testler: Retry Çözüm Değil

info@muhammetsafak.com.tr (Muhammet Şafak) — Wed, 17 Jun 2026 00:00:00 GMT

İncelememe bir pull request düştü: diff’in yarısı testti ve onları bir model yazmıştı. Yerelde geçiyorlardı. CI’da biri bir kez patladı, yeniden çalıştırınca geçti, iki gün sonra yük altında yine patladı. Koda kimse dokunmamıştı.

O test yanlış değildi. Kararsızdı (flaky) — ve kararsızlık, kendine has bir bozukluk türü.

AI kararsızlığı icat etmedi — seri üretime geçirdi

Eskiden test yazmanın bir maliyeti vardı; bu yüzden daha az yazar, her birini daha çok düşünürdün. Model bunları saniyeler içinde, yalnızca kodun o anki görünüşünden yazıyor. Eşzamanlılığı, kaynak limitlerini, bir async çağrının gerçek zamanlamasını göremez — o yüzden doğru görünen ama sessizce deterministik olmayan kalıplara uzanır:

Async işi “beklemek” için sabit bir sleep: time.Sleep(2 * time.Second), await page.waitForTimeout(2000), cy.wait(2000).
Her çalıştırmada farklı değer üreten, seed’siz bir rastgele kaynak: Math.random(), rand.Intn(100), sabit seed’i olmayan bir faker.
DOM yapısına çakılı, kırılgan bir selector — nth-child, otomatik üretilmiş bir class adı — markup azıcık kayınca kırılır.
Her şeye bir mock; böylece test bir sonucu değil bir etkileşimi doğrular — hiçbir şey yapmayan testlerle coverage kovalamak yazısında anlattığım o boş yeşilin aynısı.

Tek tek bakınca her biri makul. Ölçekte bir kararsızlık fabrikası.

Süit büyüdükçe daha az güvenilir oluyor

%0,5 ihtimalle boşuna patlayan tek bir test görünmez. Aynısından 800 tane koy, temiz bir çalıştırmada herhangi bir testin patlama ihtimali 1 − 0,995^800 ≈ %98. Patlamalar birbirinden bağımsız da değil: CI, paylaşımlı ve throttle’lı donanımda koşar; laptop’unda 50 ms’de biten async test, yük altında timeout’a düşer.

Model test eklemeye devam ettikçe bu sayı tırmanır ve süitin yanlış-kırmızı verme ihtimali kesinliğe doğru yürür. Önemsediğin geçiş, önemsemediğin gürültüde boğulur.

Retry bir koşu bandı, tedavi değil

Refleks, gürültüyü yutmak: job’u otomatik retry’la, testi flaky işaretle, quarantine’e al, bir ticket aç. Bunların hepsi reaktif — test CI’ı zaten bozduktan, çoğu zaman birden çok kez bozduktan sonra devreye girer.

Retry gerçek CI dakikası yakar ve feedback loop’u uzatır; yeni hiçbir şey öğrenmemek için iki kez ödersin.
Quarantine, sessizce büyüyen bir devre dışı test yığını üretir. O yığın borçtur ve faiziyle büyür — her atlanan test, artık kimsenin koşmadığı bir kontrol.
Ticket, backlog gürültüsüne yaşlanır ve sessizce önemini yitirir.

Hiçbiri testi deterministik yapmaz. Belirtiyi gizler ve bunun bedelini sana keser.

Patlamayı değil, anti-pattern’i yakala

Kararsız bir test nadiren ince bir sebepten patlar. Az sayıda, iyi bilinen anti-pattern yüzünden patlar — ve bunlar test daha çalışmadan, diff’te görünür. Sabit bir sleep, seed’siz bir RNG, duvar-saatine dayalı bir assertion, yapısal bir selector: her biri, test yazıldığı anda statik ve deterministik olarak tespit edilebilir.

Ben bu kontrolü commit sınırında çalıştırıyorum — değişen test dosyalarının eklenen satırları üzerinde statik bir tarama, bilinen anti-pattern’leri işaretliyor. Aynı diff, aynı sonuç; model yok, network yok. Akıllı bir race’i yakalamaz, zaten amacı bu değil. Amaç daha dar ama çok değerli: bariz kararsızlığı CI’a hiç ulaşmadan durdurmak — ki orada yakalamak yüz kat pahalı ve bir mühendisin öğleden sonrasına mal oluyor.

Testi, tespit edilecek bir şey kalmayacak şekilde tasarla

Tespit, emniyet ağı. Asıl çözüm, testi en baştan deterministik yazmak:

Sabit beklemeleri koşula dayalı beklemeyle değiştir — beklediğin duruma ulaşana kadar yokla ya da çerçevenin Eventually/waitFor’ını kullan. Saati değil, bir olguyu bekle.
Her rastgele kaynağı seed’le; test ortasında now() ve Math.random() okumak yerine deterministik bir saat ve ID enjekte et.
DOM pozisyonuna değil, role veya test id’ye göre seç.
Logic’i değil, sınırı mock’la — ve en az bir gerçek integration yolunu koru, yoksa süit var olmayan bir dünyayı doğrular.

Bu kalıp ne zaman doğru cevap olmaktan çıkar?

Statik bir kapı isabet-önceliklidir: bariz anti-pattern’leri yakalar, kendi kodunun içine gömülü bir race condition’ı değil. Kurallarını muhafazakâr tut — gürültülü bir kapı yok sayılır, yok sayılan bir kapı ise hiç olmamasından kötüdür. Akıllı kararsızlığı kaçıracaktır; tahmin etmesine izin verme.

Ve bunların hiçbiri daha zor olan okumanın yerine geçmez: test edilen sistem deterministik olmadığı için kararsız olan bir test, sana test hakkında bir şey söylemiyor. Sana sistem hakkında bir şey söylüyor.

Güvenmek için yeniden çalıştırman gereken yeşil bir CI, yeşil değildir. Kararsız bir testi öldürmenin en ucuz yeri, yazıldığı satır — sana bir build’e mal olmadan önce.

İlgili: burada anlatılan commit-sınırı kontrolünü CommitBrief’te shipledim — flaky-test dedektörü değişen test dosyalarındaki sabit sleep’leri ve seed’siz rastgeleliği, modelden önce, deterministik olarak statik yakalar.

Şema Evrimi: Sözleşmeyi Kırmadan Değiştirmek

info@muhammetsafak.com.tr (Muhammet Şafak) — Wed, 17 Jun 2026 00:00:00 GMT

Biri bir olaya zorunlu bir customer_id alanı ekledi ve üreticiyi deploy etti. Tüketicilerin yarısı henüz bu değişikliği shiplememişti. Yirmi dakika boyunca, eski tüketicilerin bir yıldır sorunsuz işlediği her mesaj birden validation’dan kalmaya başladı — ta ki rollout tamamlanana kadar. Hiçbir kod “yanlış” değildi. Bir sözleşme, ona bağlı olanların altından çekilip değiştirildi.

Bir mesajın data şekli bir API’dir. Response body yerine queue’da JSON olması onu daha az sözleşme yapmaz — daha zor bir sözleşme yapar, çünkü iki tarafı aynı anda değiştiremezsin.

Dağıtık bir sözleşmeyi atomik değiştiremezsin

HTTP API’sinin kontrol ettiğin tek bir sunucusu vardır. Yayınlanan bir mesajın ise bağımsız deploy edilen, kendi takvimlerinde olan birçok tüketicisi vardır — ve at-least-once teslimatla, eski şekille üretilmiş yoldaki mesajlar, sen yenisini yayarken hâlâ geliyordur. “Herkesin yeni şemada olduğu” bir an yoktur. Yani tek güvenli değişiklikler, eski ve yeninin bir arada var olabildiği değişikliklerdir.

Bu tek kısıt sana tüm kural setini verir.

Ne güvenli, ne değil

Bir değişiklik, eski şema altında geçerli olan data yeni şema altında da geçerliyse backward-compatible’dır — böylece erken yükselten bir tüketici, henüz yükseltmemiş bir üreticinin yaydığı mesajları hâlâ kabul eder.

Opsiyonel bir alan ekle — güvenli. Eski data onsuz olur, olur.
Bir required kısıtını kaldır (alanı opsiyonel yap) — güvenli. Eski data daha gevşek kuralı zaten karşılar.
Bir enum’ı genişlet, bir minimum’u gevşet — güvenli.

Ve ısıranlar:

Zorunlu bir alan ekle ya da opsiyonel bir alanı zorunlu yap — kırıcı. Eski data onu içermez.
Bir alanı kaldır, yeniden adlandır ya da tipini değiştir — kırıcı. Yeniden adlandırma, bir kaldırma artı bir eklemedir.
Kuralları sıkılaştır — bir enum değerini düşür, bir minimum’u yükselt, additionalProperties’i kapat — kırıcı.

Asimetri asıl mesele: gevşetmek güvenli, sıkılaştırmak değil. Bir tüketici, beklediğinden daha hoşgörülü bir data’yı, artık talep ettiği bir şeyi eksik bir data’ya göre çok daha kolay tolere eder.

Kırıcıysa, kimliği sürümle — değiştirme

Kırıcı bir değişiklikte içgüdü “şemayı güncelleyiver” demek. Deme. Mevcut bir kimliğin arkasındaki şekli değiştirmek, yukarıdaki rollout’u kıran şeyin ta kendisi. Bunun yerine yeni bir kimlik üret — yeni bir mesaj URN’i (urn:babel:orders:created.v2), yeni bir topic, yeni bir olay adı — ve ikisini paralel koştur:

Üreticiler v1 yaymaya devam eder; sen v2’yi yanında yayınlarsın.
Tüketiciler kendi takvimlerinde v2’ye göç eder.
v1’in tüketicisi kalmayınca onu emekliye ayır.

Her adımın altındaki kural: önce tüketiciler yükseltir. Hiçbir deploy edilmiş tüketicinin anlamadığı bir sürümü asla yayma. (Bu, bir mükerrer teslimat no-op olacak şekilde handler tasarlamanın aynı şekli — sırayı kontrol etmediğin için, değişikliği her sırada uygulanabilir kılarsın.)

Kuralı mekanik hâle getir

Bunların hiçbiri, cuma akşamı 5’te bir code review’da yeniden türetmek isteyeceğin bir yargı değil. Yukarıdaki uyumluluk kuralları deterministik — eski ve yeni şema verildiğinde, bir araç sana “additive, ship et” ya da “kırıcı, yeni sürüm üret” diyebilir, hiçbir görüş katmadan. O yüzden ben bunu kapıya koyuyorum: sınırda iki şemayı diff’leyip kırıcı değişiklikte build’i kıran bir kontrol — aşağı tarafa ulaşmadan önce. Orada yakalamak bir PR yorumuna mal olur; production’da yakalamak yukarıdakine benzer bir rollout penceresine.

Bu, “darboğaz aşağı kaydı” tezinin sıkıcı-altyapı ucu: şema ucuza değiştirilir ama yanlış değiştirmek pahalıdır, o yüzden bir parça araçla o ikinci maliyeti masadan kaldırırsın.

Bu ne zaman önemsizleşir?

Bir mesajın tam olarak tek bir üreticisi ve birlikte deploy olan tek bir tüketicisi varsa — tek bir servisin iç queue’su — sözleşme aslında dağıtık değildir; iki tarafı aynı anda değiştirebilirsin. O zaman bu tören fazlalıktır. Kurallar, ikinci, bağımsız deploy edilen bir tüketici var olduğu an karşılığını vermeye başlar. İlk ayını aşan çoğu olay o noktaya ulaşır.

Bir şema sahip olduğun bir struct değildir; başka servislerin etrafında plan yaptığı bir sözdür. Onu, geri alamayacağın herhangi bir sözü nasıl evrimleştirirsen öyle evrimleştir — additive olarak ya da yeni bir ad altında. Asla eskisini sessizce yeniden tanımlayarak değil.

İlgili: BabelQueue schema-validation spec’i bu uyumluluk kurallarını yazıya döker; babelqueue-registry URN-başına şemaların yaşadığı yerdir — onun bqschema aracı (ve paketlenmiş Action’ı) kırıcı değişiklikte build’i kıran sınır kontrolüdür.

Katmanlı Mimari mi, Clean Architecture mı?

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 13 Jun 2026 00:00:00 GMT

Bir Laravel projesini ilk açtığımda, tek bir “kullanıcı oluştur” işleminin yedi dosyaya yayıldığını gördüm: Controller, Request DTO, UseCase, Domain Entity, Repository Interface, Eloquent Repository ve iki yönlü bir Mapper. İçindeki tek iş kuralı, e-postanın benzersiz olmasıydı.

Bu, Clean Architecture’ın yanlış uygulanmış hâliydi — ama suç Clean Architecture’da değil. Suç, hangi projenin hangi disipline ihtiyacı olduğunu hiç sormamakta.

İki yaklaşım, kısaca

Katmanlı (layered) mimari tanıdık olandır: Controller → Service → Repository → veritabanı. Bağımlılıklar yukarıdan aşağı akar, en altta framework durur. Laravel’in kendisi de zaten budur — Eloquent bir active record, controller’lar HTTP’ye bağlı, her şey framework’e gömülü.

Clean Architecture (ve akrabaları hexagonal, onion) bağımlılık yönünü tersine çevirir: merkezde framework’ten habersiz domain durur, bağımlılıklar içeri doğru bakar. Veritabanı, HTTP, framework — hepsi en dıştaki halkada, birer detay. Domain, Laravel’in var olduğunu bilmez.

Fark felsefi değil, çok somut: katmanlı mimaride domain Eloquent’e bağımlıdır; Clean’de Eloquent domain’e bağımlıdır.

Clean Architecture neyi satın alır

Bedava değil, ama gerçek şeyler verir:

Framework’ten bağımsız test. Domain kuralları, veritabanı olmadan, saf birim testlerle koşulur. Hızlı; kırılgan değil.
Framework’ün ömründen uzun domain. İş kuralları, Laravel sürümlerinden bağımsız yaşar. On yıllık bir domain, üç major framework upgrade’i görebilir.
Birden çok teslim mekanizması. Aynı domain’i HTTP API, CLI komutu ve queue worker üzerinden çağırmak doğallaşır.

Karşılığında ödediğiniz de somut: her katman geçişinde mapping, daha çok dosya, daha çok dolaylılık. Tek satırlık bir kural için yedi dosya — yazının başındaki manzara.

Çoğu Laravel projesi için katmanlı yeter

Açık konuşayım: çoğu web uygulaması özünde CRUD’dur. Veriyi doğrula, kaydet, oku, göster. Böyle bir uygulamada Eloquent’e karşı “clean code” uğruna savaşmak, kazanılan değerden pahalıdır.

Laravel’i bir detay değil, bilinçle seçilmiş bir temel olarak kabul edin. Controller + Form Request + Eloquent model + ince bir service sınıfı — bu, projelerin büyük çoğunluğu için doğru ağırlıktır. Framework’ü kucaklamak bir ödün değil, bir karardır; tıpkı boring architecture gibi.

Yedi dosyalık bir CRUD ise spekülatif genelliğin mimari ölçekteki hâlidir: bugün olmayan bir karmaşıklık için bugünden vergi ödemek.

Clean Architecture ne zaman karşılığını verir

Disiplin, domain karmaşıklığı yüksek olduğunda gerçek getiri sağlar. Şu sinyaller varsa ciddiye alın:

İş kuralları “kaydet/oku”nun çok ötesinde: çok adımlı hesaplamalar, durum makineleri, sektörel düzenlemeler.
Bu kuralların framework’ten uzun yaşaması bekleniyor.
Aynı domain birden fazla arayüzden besleniyor — API, CLI, mesaj kuyruğu, panel.
Kural değişiklikleri sık ve riskli; veritabanına dokunmadan test edebilmek gerçek bir hız kazandırıyor.

Sigorta primlendirme, muhasebe, lojistik optimizasyonu — bu alanlarda Clean Architecture’ın dolaylılığı kendini öder. Bir blog ya da standart bir yönetim panelinde ödemez.

Hep ya da hiç değil

En sık atlanan nokta: bu bir ikili seçim değil. Aynı kod tabanında ikisi bir arada yaşayabilir.

Domain’in gerçekten karmaşık olduğu modülü — diyelim fiyatlandırma — Clean tarzı izole edin: saf domain, interface’le ayrılmış repository, framework’ten bağımsız testler. Geri kalan CRUD modüllerini düz bırakın: controller, Eloquent, ince service. Modüler monolitin sağladığı sınırlar bunu doğal kılar — her modül kendi ağırlığını taşır.

Mimari, projeye tek tip dağıtılan bir kural değil; karmaşıklığın yoğunlaştığı yere göre ayarlanan bir bütçedir.

Clean Architecture bir rozet değil, bir araç. Domain’iniz onun çözdüğü problemi yaşıyorsa paha biçilmez; yaşamıyorsa, tek satırlık bir kuralı yedi dosyaya bölen bir törenden ibaret.

Mimariyi domain seçer — moda değil.

Vibe Coding ile Production'a Çıkılır mı?

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 13 Jun 2026 00:00:00 GMT

“Yerelde çalışıyordu” cümlesinin yeni bir akrabası var: “demoda çalışıyordu.” Bir hafta önce tarif edilip dakikalar içinde ayağa kalkan, ilk kullanıcılarını bile almış bir ürün — sonra ilk gerçek yük geldiğinde yavaşlıyor, ilk meraklı kullanıcı başkasının faturasını görüyor, ilk şema değişikliği migration’da patlıyor. Üreten kişi şaşırıyor: kod çalışıyordu.

Çalışıyordu. Ama vibe coding’in düşürdüğü maliyet üretimdi; yanlış olmanın maliyeti değil. O maliyet ertelenir, silinmez — ve ertelenen maliyet faiz işletir.

Vibe coding’in ucuzlattığı şey gerçek

Strawman kurmayalım. Bir ilk sürümü çıkarmak hiç bu kadar ucuz olmamıştı: bir CRUD ekranı, bir REST uç noktası, bir form doğrulaması — tarif et, çalışsın. Prototip, throwaway, iç araç, öğrenme projesi için bu mükemmel bir hızlandırıcı.

Ucuzlatmadığı tek şey var: veri modeli, güvenlik sınırı ve failure mode hakkında yanlış olmanın bedeli. Bu üç şey production’da yanlışsa, fatura build anında değil, çok sonra — genelde gece 2’de — gelir.

Fatura build’de değil, production’da görünür

Vibe coding ile çıkan sistemlerde tekrar tekrar gördüğüm dört kalıp. Hiçbiri “kod derlenmiyor” tipinde değil; hepsi intent ile gerçeklik arasındaki boşlukta yaşıyor.

1. Göç edemeyen veri modeli. Dolu bir tabloya NOT NULL kolon, DEFAULT’suz. Boş tabloda sorunsuz, production tablosunda fail. Daha derini: ilişkileri yanlış kurulmuş bir şema altı ay sonra basit bir özelliği imkânsız kılar. Veri modelini sonradan düzeltmek bir refactor değil, bir veri göçü riskidir — ve en pahalı anda, gerçek veriyle yapılır.

2. Düşman girdiyi hesaba katmayan güvenlik. Kimlik kontrolünden geçen ama sahiplik kontrolünden geçmeyen object ID’ler (IDOR), query’ye ulaşan kullanıcı girdisi, koda gömülü secret. Agent’ın ürettiği “standart” çözüm, girdinin düşman olabileceğini varsaymaz; çünkü ona sorulan soru “bu çalışsın” idi, “bu saldırıya dayansın” değil.

3. Ölçeklenmeyi görmeyen erişim deseni. Döngü içinde sorgu (N+1), SELECT *, pagination’sız liste, eş zamanlı olması gereken yerde senkron çağrı. On satırlık tabloda görünmez; yüz binlik tabloda p95’i uçurur.

4. Gözlemlenemeyen ve geri alınamayan sistem. Log yok, metrik yok, rollback planı yok. Kırıldığında neden kırıldığını göremezsiniz — ki vibe-coded sistemde en çok ihtiyaç duyacağınız şey budur.

Ortak payda şu: araç en güvenli göründüğü yerde en tehlikeli. Yaygın kalıpları sağlam yazar; problemin kendine özgü boyutunu görmeden “standart” bir çözüm verir. Standart çözüm, sormadığınız problemin cevabıdır.

Çıktının kalitesini belirleyen: yazma hızı değil, denetim

Aynı agent’ı üç farklı elde düşünün. Fark, kimin daha hızlı yazdırdığı değil; sorulan sorunun ve yapılan review’un kalitesi.

Hiç/çok az bilgi. Soruyu çerçeveleyemez, çıktıyı eleştirel okuyamaz. “Standart çözüm” yukarıdaki dört kalıpla birlikte production’a olduğu gibi çıkar. “Çalışıyor” ile “doğru çalışıyor” arasındaki farkı henüz hissedemez.
Az-orta bilgi. Bazı soruları doğru kurar, çıktının bir kısmını yakalar. Tavanı sistemin sınırlarında: yük altında nerede kırılır, bu soyutlama doğru mu, bu veri modeli hangi değişikliği kaldırır. Sonuç: iyi parçalar, kırılgan bütün.
Senior + sistem mimarisi. Agent bir ikame değil, bir çarpan. Plan yaptır → onayla → adım adım yazdır → bir junior’ın kodu gibi review et → savunamayacağın satırı merge etme. Bu disiplinin somut hâli ayrı bir yazıda: AI-Assisted Engineering Workflow’um. Bu elde hız artar, kalite düşmez — çünkü muhakeme insanda kalır.

Bu bir bütçe ifadesidir, ideoloji değil: senior, ertelenen maliyete karşı en ucuz sigortadır. Doğru veri modelini baştan kurmak bir öğleden sonra; yanlışını canlı sistemde düzeltmek bir çeyrek. “Para kazanınca düzeltiriz” bu yüzden absürt — para kazandıran ürün, aynı zamanda elinizi bağlayan, göçü en riskli üründür. Senior sonradan değil, önceden ucuzdur.

Ne zaman vibe coding doğru cevap?

Her öneri gibi bunun da bir geçerlilik sınırı var — ve sınırı söylemeden öneri yapmam.

Vibe coding doğru araçtır: prototip, throwaway demo, hobi, gerçek verisi/kullanıcısı olmayan iç araç, öğrenme. Buralarda yanlış olmanın maliyeti düşük olduğu için ertelemek rasyoneldir.

Denklem şu üç şeyden biri masaya gelince çevrilir: gerçek kullanıcı, gerçek veri, gerçek para (ya da gerçek uptime taahhüdü). O eşikten sonra ertelenen maliyet faizini ödetmeye başlar ve direksiyonu tutan birine ihtiyaç doğar.

Yapay zekâ agent’larıyla üretim mümkün, hatta gerçekten hızlı. Ama agent, kodu kimin yazdığını değiştirdi; kimin sorumlu olduğunu değil. Vibe coding üretimi ucuzlattı, yanlış olmanın maliyetini değil — ve o maliyet, production’a kimin elinde çıktığına bakar.

"İleride Lazım Olur" Kodunun Production Faturası

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 06 Jun 2026 00:00:00 GMT

Bir code review’da şu yorumla sık karşılaşıyorum: // ileride başka sağlayıcı da gelebilir. Hemen altında tek implementasyonlu bir interface, onu yaratan bir factory ve hiç okunmayan bir config anahtarı durur. Planlanan ikinci sağlayıcı yoktur — sadece ihtimali vardır.

Bu kod bedava yazıldı sanılır. Değil. “İleride lazım olur” diye eklenen her esneklik, kullanılmaya başlanana kadar her gün faiz ödeyen bir borçtur.

Spekülatif genellik nedir?

Spekülatif genellik, bugün var olmayan bir gereksinim için bugünden esneklik inşa etmektir. Tek satıra yetecek yere bir strateji deseni, tek tipe yetecek yere generic bir parametre, tek çağrı için bir event sistemi.

Gerekçe hep aynı kelimelerle gelir: “ileride”, “ne olur ne olmaz”, “genişletilebilir olsun”. Hepsi geleceğe dair bir tahmindir. Ve tahmin, bir kod tabanının en pahalı parçasıdır.

Faturanın kalemleri

Kullanılmayan esneklik boş durmaz; her gün şu kalemleri öder:

Okuma maliyeti. Kodu okuyan herkes “bunun ikinci bir kullanımı var mı?” diye arar, bulamaz, kafası karışmış hâlde devam eder. Esneklik, var olmayan bir senaryoyu sürekli düşündürür.
Bakım maliyeti. Soyutlama, altındaki gerçek koda her dokunuşta birlikte güncellenir. Boş bir katman bile bakım ister.
Hata yüzeyi. Çalışmayan kod, çalışan kodu kırabilir — yanlış dallanma, ölü bir branch’te unutulmuş bir bug, hiç test edilmemiş bir yol.
Yanlış soyutlamaya kilitlenme. En pahalısı bu. Bugün tahminle çizdiğiniz interface, yarın gerçek ihtiyaç geldiğinde neredeyse hiç uymaz — ama artık onu söküp atmak, baştan yazmaktan zordur.
Test yükü. Her fazladan dolaylılık, test kurulumunu uzatır; mock sayısını artırır.

Boring architecture yazısındaki “karmaşıklık bütçesi” burada da geçerli: spekülatif genellik o bütçeyi, hiçbir şey teslim etmeden harcar.

Tahmin neredeyse hep yanlış çıkar

“İleride lazım olur” kodunun en acı yanı şu: ileride gerçekten bir şey lazım olduğunda, lazım olan şey tahmin ettiğiniz şey değildir.

İkinci ödeme sağlayıcısı sonunda gelir — ama sizin interface’inizin hiç varsaymadığı bir async webhook akışıyla gelir. İkinci kiracı (tenant) gelir — ama satır bazlı izolasyonla değil, ayrı şema ile. Önceden çizilmiş esneklik, gerçek gereksinimle karşılaşınca bir yardım değil, bir engel olur: önce onu kaldırmanız gerekir.

Domain’i en az tanıdığınız an, projenin ilk haftasıdır; geleceğe dair en kötü tahminleri tam da o an verirsiniz. Modüler monolit yazısında sınırların ilk haftada neredeyse kesin yanlış çizileceğini söylemiştim — aynı şey her erken soyutlama için geçerlidir.

YAGNI’yi pratikte uygulamak

“You Aren’t Gonna Need It” bir tembellik izni değil, bir zamanlama kuralıdır: esnekliği, ihtiyaç kanıtlandığında ekle — tahmin edildiğinde değil.

Pratik karşılığı:

Bugünün bilinen vakası için yaz. Tek sağlayıcı varsa tek sağlayıcıyı yaz. Düz, doğrudan, okunur.
Üç kuralı. Bir kalıbı soyutlamadan önce üç gerçek kullanımını bekle. İki, tesadüf olabilir; üç, bir desendir.
Dikişi sonra aç. İkinci sağlayıcı gerçekten geldiğinde interface’i çıkarmak bir IDE refactor’ı — birkaç saat. O birkaç saati bugünden ödemenin hiçbir getirisi yok.

Asimetri şurada: düz kodu sonradan soyutlamak kolaydır. Yanlış soyutlamayı sonradan düzleştirmek zordur. Bu asimetri YAGNI’den yanadır.

Ne zaman önden esneklik haklı?

Her şeyi son ana bırakmak da değil. Ayrım, kararın geri dönülebilir olup olmadığında:

Geri dönülebilir kararlar (çift yönlü kapı). Bir sınıfın iç yapısı, bir fonksiyonun imzası, kod organizasyonu. Bunları sonradan değiştirmek ucuz — bugünden esnek tutmaya gerek yok.
Geri dönülmesi zor kararlar (tek yönlü kapı). Veritabanı şeması, dışarıya verilmiş bir API kontratı, veri formatı, güvenlik sınırı. Bunlarda ileriyi düşünmek spekülasyon değil, sorumluluktur — çünkü hatanın bedeli production’da veri göçü demektir.

Kural şu: kodun içinde cömertçe basit ol; dışa açtığın ve veriye yazdığın yerde tedbirli ol. Esnekliği, geri almanın gerçekten pahalı olduğu yere sakla.

“İleride lazım olur” cümlesi bir gereksinimi değil, bir korkuyu ifade eder. Kodu korkuyla değil, kanıtla büyütün.

En kolay silinen kod, hiç yazılmamış olandır.

Ardışık Numara Üretiminde Race Condition ve Gap: JIT Rezervasyon

info@muhammetsafak.com.tr (Muhammet Şafak) — Wed, 03 Jun 2026 00:00:00 GMT

Resmî entegratörden dönen hata kısaydı: Duplicate / Already Exists. İki worker aynı saniyede aynı fatura numarasını üretmiş, ikisi de aynı numarayla göndermiş, biri reddedilmişti. O seride fatura kesimi tıkandı ve arkadaki her iş onun gerisinde bekledi.

Bu kalıbı yasal belge numaralandıran birkaç sistemde aynı şekilde kurdum; her seferinde aynı iki kısıt çatışır ve akla ilk gelen çözümlerin hepsi kırılır. Aşağıda hem neyin kırıldığını hem de bugün kullandığım çözümü — JIT rezervasyon — anlatıyorum.

İki kısıt aynı anda

Yasal belge numaralandırmasını (e-fatura, makbuz, irsaliye) zorlaştıran şey, iki kısıtın birlikte sağlanma zorunluluğudur:

Mükerrersiz — aynı numara iki kez kullanılamaz.
Boşluksuz — seride atlanan numara olamaz. Denetimde 1454 yoksa, “nereye gitti” sorusunun cevabı verilmek zorundadır.

Her kısıt tek başına kolaydır. AUTO_INCREMENT mükerrersizliği halleder; bir sayaç boşluksuzluğu halleder. Ama numaranın başarısız olabilen bir dış sisteme (entegratör, GİB) gönderildiği an, ikisini birden tutmak bir kilit değil zamanlama problemine döner.

Sistemin şekli — ve onu açığa çıkaran göç

Bu problem aslında bir mimari göçün kuyruğunda çıktı. Eskiden akış senkrondu: kullanıcı panelde “Faturamı oluştur” butonuna basar, fatura o request içinde, kullanıcı sonucu ekranda beklerken kesilirdi. O modelde numaralandırma yıllarca “çalıştı” — çünkü her istek, kullanıcının bloke beklemesi boyunca fiilen seri işleniyordu; gerçek bir eşzamanlılık hiç oluşmuyordu.

Sonra akışı ayrıştırdım. Bugün farklı proje ve framework’ler faturalarını ortak bir RabbitMQ kuyruğuna yazıyor; kuyruğu sürekli dinleyen ayrı bir consumer/worker mikroservisi mesajları tüketiyor, e-fatura formatına çeviriyor ve entegratöre iletiyor.

Proje A (framework X) ──┐
Proje B (framework Y) ──┤
Scheduler (cron)      ──┼──►  [ ortak RabbitMQ ]  ──►  Consumer mikroservisi (N worker)  ──►  Entegratör API ──► GİB
Kullanıcı aksiyonu    ──┘

Buton artık senkron çağrı yapıp orada faturalandırmıyor; HTTP ile kuyruk arasındaki sınır tam buradan geçer: dış API çağrısı saniyeler sürebilir, onu bir request-response döngüsünde tutmak istemedim. Sonuç event-driven bir yapı — ölçeklenebilir, dayanıklı ve üreticilerden bağımsız.

Ama bu ayrıştırma, yıllardır gizli kalan bir şeyi açığa çıkardı. Senkron model numaralandırmayı kazara seri işliyordu; consumer’ı eşzamanlı çalıştırır çalıştırmaz o kaza ortadan kalktı ve altta hep var olan race condition yüzeye vurdu. Bug küçük ve gözden kaçacak cinstendi — tam da yalnızca eşzamanlılık gerçek olunca ortaya çıktığı için. Buradan sonra tüm tasarım kararı tek bir soruda düğümlenir: numara nereden ve ne zaman gelir?

Bir göç eşzamanlılık hatası yaratmaz; seri bir yürütme modelinin sakladığı hatayı görünür kılar.

Naif çözüm 1 — gönderim anında `MAX()` (race condition)

İlk kurduğumda numarayı gönderim anında ürettim:

SELECT MAX(invoice_no) + 1 FROM outgoing_invoices WHERE series = 'A';

Tek worker’la kusursuz çalıştı. İkinci worker’ı açtığım gün çöktü:

Worker-1: SELECT MAX(...) → 1453
Worker-2: SELECT MAX(...) → 1453   (Worker-1 henüz INSERT etmedi)
Worker-1: API'ye 1454 ile gider  ✓
Worker-2: API'ye 1454 ile gider  ✗ Duplicate

Klasik read-modify-write race condition’ı. MAX() okuması ile yazma arasındaki pencere, iki worker’ın aynı değeri görmesine yetecek kadar geniş. Hacim arttıkça pencere genişler — yani sorun yük altında, en kötü zamanda büyür.

Naif çözüm 2 — numarayı baştan üret (gap)

İkinci refleksim çoğu geliştiriciyle aynıydı: numarayı mümkün olan en erken yerde, kuyruğa mesaj atarken üret ve mühürle. Mükerrerlik bitti, ama gap doğdu:

1454 numaralı fatura kuyrukta beklerken işlenir.
Entegratörde kalıcı bir hata alır (geçersiz VKN, iş kuralı reddi) ya da kullanıcı kuyruktayken iptal eder.
O fatura düşer; arkadan gelen 1455 ile yola devam eder.
Seride 1454 boşluğu kalır — denetimde hesabı verilemeyecek bir gap.

İkilem buydu: numarayı geç üretirsem race, erken üretirsem gap. Mesele bir yöntemi diğeriyle değiştirmek değildi; ikisini birden tutmaktı.

Yaklaşım	Mükerrersiz	Boşluksuz	Kırılma
Gönderimde `MAX()+1`	✗	✓	Paralel worker’da çakışma
Enqueue’da üret	✓	✗	Başarısız/iptal → gap
JIT rezervasyon	✓	✓	— (maliyeti aşağıda)

Neden hazır bir sequence yetmez

“Sayaç boşluksuzluğu halleder” dedim; ama veritabanının kendi sequence’ı (SEQUENCE, AUTO_INCREMENT) bunu yapmaz — tersine, gap üretmek üzere tasarlanmıştır. Sequence performans için transaction’dan bağımsız ilerler: nextval çağıran transaction rollback olsa bile tüketilen değer geri gelmez. PostgreSQL’de başarısız bir INSERT’in id’si kalıcı olarak atlanır; MySQL AUTO_INCREMENT aynı şekilde davranır. Bu çoğu sistemde istenen davranıştır — birincil anahtarda boşluk kimsenin umurunda değil. Bizim problemimizde ise tam olarak kaçındığımız şey. Bu yüzden boşluksuzluğu uygulama katmanında, açık bir sayaç tablosuyla yönetiyorum.

İkinci itiraz: “tek satırlık sayaç tablosu kendi başına bottleneck olmaz mı?” Olmaz — çünkü o satırın kilidi yalnızca UPDATE ... SET next_no = next_no + 1 deyimini içeren kısa transaction commit olana kadar, yani tek haneli milisaniyeler boyunca tutulur; dış çağrı boyunca değil. Yine de yük çok yüksekse seriyi bölmek (A, B, C… ayrı sayaçlar) contention’ı doğrusal düşürür; her serinin kendi boşluksuz dizisi olur ve seriler birbirini beklemez.

JIT rezervasyon: state’i dış çağrıdan bir ms önce mühürlemek

Bende çözüm şu oldu: numarayı ne çok erken ne çok geç, dış API çağrısından tam bir an önce üretip kalıcılaştırmak. İki parça ekledim:

Atomik bir sekans sayacı (invoice_sequences) — seriyi tek kaynaktan ilerletir.
Taslak fatura üzerinde bir rezervasyon kolonu (reserved_no) — üretilen numaranın, dış çağrı başarısız olsa bile korunduğu yer.

Kilidi yalnızca rezervasyon için tutuyorum; dış çağrı kilidin dışında:

│── TX başlat ─────────────────│
│  invoice'u lockForUpdate     │
│  reserved_no boşsa:          │   ← satır kilidi yalnızca burada (tek haneli ms)
│    sequence++ → reserved_no  │
│    status = SENDING          │
│── COMMIT ────────────────────│
                                └──► Entegratör API çağrısı (200ms–2sn, kilit YOK)
                                      ├─ başarılı → outgoing_invoices'a INSERT
                                      └─ başarısız → reserved_no DURUR, status = ERROR

Sayacı satır kilidiyle atomik ilerletiyorum:

BEGIN;
  SELECT next_no FROM invoice_sequences WHERE series = 'A' FOR UPDATE;
  UPDATE invoice_sequences SET next_no = next_no + 1 WHERE series = 'A';
COMMIT;  -- kilit ms içinde açılır; bir sonraki worker beklemeden devralır

Worker tarafında rezervasyonu idempotent kılan tek bir kontrol var:

$invoice = DB::transaction(function () use ($invoiceId) {
    $invoice = Invoice::whereKey($invoiceId)->lockForUpdate()->first();

    // Retry'da numara KORUNUR — yeniden üretilmez.
    if ($invoice->reserved_no === null) {
        $invoice->reserved_no = $this->sequence->next('A'); // FOR UPDATE'li sayaç
        $invoice->status      = 'SENDING';
        $invoice->save();
    }

    return $invoice;
}); // TX burada commit olur; kilit kalkar

$this->integrator->send($invoice); // saniyeler sürebilir — kilit tutmuyoruz

Kritik satır if ($invoice->reserved_no === null). Bir fatura hata alıp retry edildiğinde alan doludur; yeni numara üretmem, eldekini korurum. Aynı fatura kaç kez denenirse denensin tek bir numara tüketir. Gap’i kapatan yarı budur: başarısız fatura numarasını kaybetmez, üzerinde asılı tutar ve aynısıyla yeniden dener.

Erken commit neden pazarlık konusu değil

Kalıbın kalbi erken commit. Yanlış yaparsanız tüm kalıp bir bottleneck’e döner.

Naif refleks, “atomik olsun” diye tüm işi tek transaction’a sarmaktır: kilidi al, numarayı üret, dış API’yi çağır, sonra commit et. Bu felakettir. Entegratör çağrısı 200ms ile 2 saniye arası sürer; o süre boyunca satır kilidi tutulursa aynı seriyi bekleyen her worker sıraya girer. Throughput, tek bir dış çağrının gecikmesine iner — saniyede onlarca fatura kesmesi gereken sistem, saniyede bire düşer.

Bu yüzden kilidi yalnızca rezervasyon için tutup hemen commit ediyorum. Kilit tek haneli milisaniyede açılır; paralel worker’lar 1454, 1455, 1456... rezerve etmeye devam eder. Dış çağrının yavaşlığı artık kimseyi bloklamaz.

Kural: kilit DB state’i için tutulur, dış I/O için değil. Bir transaction içinde network çağrısı varsa, kilit süreniz o network’ün insafına kalmıştır.

Birden çok üreticiyi güvende tutmak

Birden çok üretici (scheduler, kullanıcı butonu, farklı projeler) aynı seriyi beslediği için, numara tek bir noktadan rezerve edilmek zorunda. Hepsi consumer aşamasında aynı reserved_no kontrolünden geçer. Üretici kim olursa olsun rezervasyon kaynağı tektir; numara üretimi üreticiye değil, consumer’daki tek koda bağlıdır. Numarayı üreticide (enqueue anında) üretmeyi denemek, bizi yukarıdaki “erken üret → gap” tuzağına geri götürürdü; o yüzden rezervasyon tek bir yerde, consumer’da yaşar.

İkinci mesele queue starvation’ı. Scheduler’ın toplu bastığı binlerce mesaj, canlıdaki bir kullanıcının anlık isteğini ezmemeli — yoksa kullanıcı, arkasında 4.000 toplu işin olduğu bir kuyruğun sonunu bekler. RabbitMQ’da priority queue ile kullanıcı isteklerini yüksek öncelikle araya sokuyorum; toplu iş arka planda akarken buton tetikli iş loading ekranını saniyelere değil milisaniyelere indirir. Öncelik doğruluğu değiştirmez — numara yine tek kaynaktan gelir — yalnızca adalet ekler. (Kuyruğun neden ve nasıl tıkandığı ayrı bir konu: Laravel queue production’da neden yavaşlar.)

Dual-write problemi ve orphan recovery

Geriye en sinsi edge case kalır. API çağrısı başarılı olur ama yanıtını yerel DB’ye yazarken worker çöker ya da network kopar. Entegratörde fatura yasal olarak kesilmiştir; sizin tarafınızda ise hâlâ SENDING statüsünde, numarası üzerinde asılı durur. Bu klasik dual-write problemidir: iki ayrı sistemi tek bir atomik işlemde tutamazsınız. Worker’ın deploy ya da ölçeklenme sırasında yarıda kapanması da aynı izi bırakır — graceful shutdown bunu azaltır ama sıfırlamaz; tasarım yine de bu izi temizleyebilmeli.

Çözüm, asılı kalanı tespit eden bir orphan recovery servisi. SENDING statüsünde 5 dakikadan uzun bekleyen faturaları tarar ve kör bir retry atmaz — önce entegratörde bir idempotency check yapar:

Bu numarayla fatura entegratöre gitmiş mi?
Gittiyse: yerel DB’yi onarır (outgoing_invoices’a yazar, statüyü kapatır). Yeni numara üretmez.
Gitmemişse: aynı reserved_no ile güvenle yeniden dener.

Bunu mümkün kılan şey, numaranın çağrıdan önce mühürlenmiş olması. Numara elde olduğu için sorgu deterministiktir: “şu numara orada mı?” Numara çağrı sırasında üretilseydi, neyi soracağınızı bile bilemezdiniz. JIT rezervasyon, recovery’yi tahmin işi olmaktan çıkarıp bir lookup’a indirir.

Bir not: entegratör kalıcı olarak hata veriyorsa (geçici değil), orphan servisi sonsuza kadar denememeli. Dış servise yüklenmeyi kesmek için araya bir circuit breaker koyuyorum; numara korunur, fatura ERROR’da bekler, ama entegratöre saniyede yüzlerce boş istek gitmez.

Ne zaman bu kalıbı bırakırsınız?

Bu makine ucuz değil — bir rezervasyon kolonunun yaşam döngüsü, atomik bir sayaç, bir orphan servisi ve entegratörde idempotency check zorunluluğu getirir. Karşılığında neyi satın aldığınızı bilmiyorsanız ödemeyin. Şu durumlarda kurmuyorum:

Gap serbestse. Numaranız yasal olarak boşluksuz olmak zorunda değilse (iç referans, sipariş no, log id), düz bir DB sequence ya da AUTO_INCREMENT yeter. Gap’i kovalamak için bu mekanizmayı kurmak, olmayan bir problemi çözmektir.
Dış çağrı yoksa. Numara üretimi ile kalıcılaştırma aynı transaction’da kalabiliyorsa (araya başarısız olabilen bir I/O girmiyorsa), rezervasyon kolonuna gerek yok; tek bir FOR UPDATE sayacı problemi bitirir.
Tek worker, düşük hacim. Paralellik yoksa race condition da yoktur. Bir global advisory lock ya da tek tüketicili kuyruk, JIT makinesinden çok daha basit ve yeterlidir.

Kalıba ihtiyaç, üç koşul birlikte doğduğunda başlar: boşluksuzluk yasal zorunluluk, üretim paralel ve son adım başarısız olabilen bir dış çağrı. Üçü birden yoksa daha sade bir çözüm vardır — onu seçin.

Sıralı, boşluksuz numara üretmek bir kilit sorunundan çok bir zamanlama sorunu. Numarayı dış dünyaya gitmeden tam bir an önce mühürlersiniz: race’i engelleyecek kadar geç, gap’i engelleyecek kadar erken. Geri kalan her şey — erken commit, idempotent retry, orphan recovery — o tek mührün etrafına dizilir.

Mikroservise Ne Zaman Geçerim?

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 30 May 2026 00:00:00 GMT

Bir planlama toplantısında “bu monolit artık çok büyüdü, mikroservislere bölelim” cümlesini duyduğumda ilk sorum hep aynı oluyor: hangi ölçüm bunu söylüyor?

Cevap çoğu zaman bir ölçüm değil. Bir his — “kod tabanı kocaman” —, bir blog yazısı ya da bir özgeçmiş kaygısı. Üçü de gerçek etkenler, ama hiçbiri mimari bir gerekçe değil.

Modüler monolit yazısında sınırları erken çizip dağıtımı geç yapmayı savunmuştum. Bu yazı o “geç”in ne zaman geldiğini — ve gelmediğini nasıl anlayacağınızı — anlatıyor.

Mikroservis bir çözüm değil, bir takas

Mikroservis mimarisi özünde tek bir şeyi değiştirir: modüller arası bir method çağrısını bir network çağrısına dönüştürür. Aldığınız şey bağımsız deploy ve bağımsız ölçekleme. Karşılığında ödediğiniz şey uzun:

In-process’te ücretsiz olan her çağrı artık serializasyon, latency ve partial failure demek.
Tek bir DB transaction’ı yerine saga, outbox, eventual consistency.
Tek bir log akışı yerine, distributed tracing olmadan takip edilemeyen bir istek yolu.
Tek bir deploy yerine, versiyonlanması ve geriye uyumlu tutulması gereken servis kontratları.
Compiler’ın doğruladığı bir refactor yerine, kimsenin doğrulamadığı bir network kontratı.

Bunların hiçbiri “kötü” değil; hepsi gerçek sistemlerde gerçekten ödenen bedeller. Asıl soru şu: bu bedeli bir şeyin karşılığında mı ödüyorsunuz, yoksa peşin mi?

Geçişi haklı çıkarmayan gerekçeler

Mikroservis kararını en sık tetikleyen sebepler, ne yazık ki en zayıf olanlar.

“Kod tabanı çok büyük.” Büyük kod tabanının çözümü modül sınırı, dürüst dosya organizasyonu ve ölü kod temizliğidir — ayrı deploy değil. 200 bin satırlık bir monolit ile 20 servise bölünmüş 200 bin satır aynı miktarda koddur; ikincisi sadece araya network koymuş hâlidir.

“Deploy yavaş ve korkutucu.” Yavaş pipeline’ın çözümü pipeline’ı hızlandırmaktır. Korkutucu deploy’un çözümü test kapsamı, aşamalı yayın ve hızlı rollback’tir. Bunların hiçbiri sistemi bölmeyi gerektirmez; bölmek aksine deploy sayısını artırır.

“Bağımsız ölçeklemem lazım.” Monolitin kendisi de yatayda ölçeklenir: aynı uygulamayı bir load balancer arkasında N kopya çalıştırmak mikroservis istemez. Bağımsız ölçekleme ancak modüllerin kaynak profili gerçekten ayrıştığında anlam kazanır — ki bu ayrı bir madde, aşağıda.

“Modern mimari bu.” Modernlik bir mimari gerekçe değil. Bir sistemin iyi olup olmadığını, kaç parçaya bölündüğü değil, bir hatayı gece 2’de izlenebilir kılıp kılmadığı söyler.

“Netflix böyle yapıyor.” Netflix’in mikroservisi finanse eden bir ölçeği ve yüzlerce mühendisi var. Üç kişilik bir ekip bu mimariyi kopyaladığında Netflix’in çözdüğü problemi değil, yalnızca operasyon yükünü kopyalar. Bu, boring architecture yazısındaki innovation token mantığının ta kendisi: bütçeyi yanlış yere harcamak.

Ortak hata kalıbı: bunların hepsi gerçek rahatsızlıklar, ama hiçbiri mikroservisle iyileşmiyor. Doğru hastalığa yanlış ilaç.

Geçişi haklı çıkaran ölçülmüş sinyaller

Modüler monolit yazısında bir modülü servise çıkarmak için dört sinyal saymıştım. Sistem ölçeğinde de eşik aynı — şu sinyallerden en az biri ölçülmüş olmalı:

Ölçeklenme profili ayrışıyor. Bir parça kaynakları geri kalanından bambaşka tüketiyor: sürekli CPU’yu doyuran bir rapor/PDF motoru, ya da dakikada on binlerce hafif çağrı alan bir bildirim modülü. İkisini tek deploy biriminde tutmak, birini diğerinin kapasite planına mahkûm eder. Bunu metrikle gösterebiliyorsanız ayırmak yatay ölçeklemeden ucuza gelir.
Sahiplik organizasyonel olarak ayrıştı. Ekip sayısı büyüdü ve aynı deploy hattındaki release çakışması artık ölçülebilir bir gecikme. Üç ekip her gün birbirinin deploy’unu beklemeye başladıysa, sınır artık teknik değil organizasyoneldir — Conway yasası faturayı kesiyordur.
Farklı bir runtime gerçekten gerekiyor. Bir iş yükü PHP’de pahalı, Go ya da Rust’ta belirgin biçimde ucuz — ve bu “daha hızlı olur” hipotezi değil, ölçülmüş bir darboğaz. O parçayı ayrı bir serviste farklı bir dille çalıştırmak gerekçeli.
Hata izolasyonu zorunlu ve process içinde garanti edilemiyor. Bir modülün çökmesi gerçekten geri kalan sistemi düşürmemeli ve bunu tek process içinde sağlayamıyorsunuz.

Dördünün ortak noktası: hepsi ölçülür. “Sanırım”, “ileride”, “olabilir” ile başlayan hiçbir cümle bu listede yok. Sinyal bir grafikte görünmüyorsa, henüz sinyal değildir.

Hepsini değil, bir modülü

Sinyal geldiğinde bile doğru hamle “monoliti mikroservislere bölmek” değildir. Doğru hamle, sinyali veren tek modülü servise çıkarmaktır.

Modüler monolitle başladıysanız bu zaten mekanik bir iş: sınır net, public yüzey tek bir sınıf. O modülü strangler kalıbıyla dışarı alırsınız — yeni servis ayağa kalkar, çağrılar kademeli ona yönlenir, eski kod silinir. Geri kalan sistem mutlu mesut monolit olarak kalır.

Big-bang rewrite — her şeyi aynı anda servislere bölmek — bilinen en pahalı ve en sık başarısız olan göç biçimidir. Bir sistemi tek seferde değil, sinyal verdikçe parça parça ayırın.

Monolit ne zaman yanlış cevaba dönüşür?

Monolit, yukarıdaki sinyallerden hiçbiri ölçülmediği sürece doğru cevaptır. Yanlış cevaba dönüştüğü an da bellidir: birden çok ekip aynı deploy biriminde sıkıştığında, bir parçanın kaynak profili sistemin geri kalanını rehin aldığında, ya da bir bileşenin çöküşü düzenli olarak tüm sistemi düşürdüğünde.

O gün geldiğinde mikroservise geçmek bir yenilgi değil — planlanmış bir adımdır. Sınırları baştan çizmiş olmanın bütün değeri de buradadır: geçiş, korkutucu bir göç değil, sırası gelmiş bir karar olur.

Mikroservis bir hedef değil, bir faturadır. O faturayı ödemek için bir sebebiniz olmalı — ve o sebep bir grafikte görünmeli, bir blog yazısında değil.

Sinyali bekleyin; kararı moda değil, ölçüm versin.

Gitflow mu, GitHub Flow mu? Neye Göre Seçiyorum?

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 23 May 2026 00:00:00 GMT

Yeni projenin ilk haftası, kick-off toplantısı, kahve daha soğumadan biri soruyor: “Hangi git workflow’unu kullanalım?” Sonraki 40 dakikada Gitflow şemaları çizilir, GitHub Flow savunulur, biri “trunk-based” der ve kimse zemin bulmadan toplantı biter.

Cevap o toplantıda değil — ürünün kendisinde duruyor.

İki modelin mekaniği, kısaca

Gitflow. main (prod), develop (entegrasyon), feature/* (geliştirme), release/* (sürüm hazırlığı), hotfix/* (acil yamalar). Sürüm odaklı. Bir özellik feature → develop → release → main yolunu izler.
GitHub Flow. Tek main ve ondan dallanan kısa ömürlü branch’ler. Her merge prod’a deploy edilebilir. Sürüm kavramı yok — tek yaşayan sürüm vardır, o da prod’daki.

İkisi de gerçek projelerde gerçekten çalışıyor. Soru hangisinin “doğru” olduğu değil, hangisinin ürününüzün şekline uyduğu.

Gitflow’un doğal habitatı

Gitflow, “aynı anda birden çok sürüm yaşıyor” gerçeği olan ürünler için tasarlandı:

Mobil uygulamalar — store onay süresi nedeniyle 3.4 cep telefonlarına ulaşırken 3.5 review’da, 3.6 develop’ta yaşar.
SDK’lar ve kütüphaneler — kullanıcının yükselme temposu sizin elinizde değil; 2.x’i bir süre destekliyorsunuz.
On-premise / packaged yazılım — müşteri “biz 4.2’deyiz” der; bu sürüme hotfix vermek bir lüks değil, sözleşme.
Hardware ile birlikte gönderilen yazılım — firmware ile koordine sürüm pencereleri.

Bu sahnelerde release/* branch bir bürokrasi değil, paralel zaman çizgilerinin yaşadığı yerdir. hotfix/* lane’i de “müşteri prod’da yanıyor ama biz develop’tayız” probleminin doğal cevabıdır.

GitHub Flow’un doğal habitatı

GitHub Flow ise tek yaşayan sürüm gerçeği olan ürünlerde nefes alıyor:

Web uygulamaları, SaaS — kullanıcının kullandığı sürüm her zaman prod’daki.
İç araçlar, dashboard’lar — tek bir kurulum, sürekli güncel.
API servisleri (versiyonsuz ya da rotalarla versiyonlanmış) — geriye uyumluluk kodda yaşar, branch’te değil.

Burada release/* branch bir altyapı değil, gereksiz bir katmandır. Hotfix de ayrı bir lane değildir — sadece sıraya giren bir PR’dır.

Neyi gerçekten seçiyorum

Üç soruya verdiğim cevap, branch stratejisini benim yerime seçiyor:

Aynı anda kaç sürüm canlı? Bir tane → GitHub Flow. Birden fazla → Gitflow.
Müşteri deploy frekansımı görüyor mu? Hayır, ben istediğim zaman deploy ediyorum → GitHub Flow. Evet, sürümler arası bir sözleşme var → Gitflow.
Hotfix’in prod’a giderken bir “release” üzerinden gitmesi gerekiyor mu? Hayır → GitHub Flow. Evet → Gitflow.

Üçü de aynı yöne işaret ediyorsa karar verilmiştir. Karışıyorsa, ürünün şekli henüz oturmamıştır — o zaman geçici olarak basit olanı, GitHub Flow’u seçiyorum; çünkü GitHub Flow’dan Gitflow’a geçmek, tersine göre daha küçük bir göç projesidir.

Yaygın eşleşme hataları

İki modeli yanlış yere koyduğum (ya da bir başkasının koyduğunu izlediğim) durumlar:

SaaS’ta Gitflow. Tek sürüm yaşayan bir web app’te develop branch gereksiz bir gölge prod yaratır; PR’lar iki kez merge edilmek zorunda kalır. Sonuç: kazanılan izolasyon, ödenen sürtünmeye değmiyor.
Packaged üründe GitHub Flow. Aynı anda 3.x’i alan müşteri varken main’i 4.x ile dolduran ekip, bir hotfix istendiğinde geriye dönmek için olmayan bir branch’i aramaya başlar. Bu noktada “Gitflow’u sonradan kurmak” bir göç projesidir.
Karma model “kendi sürümümüzü uyduralım.” Çoğu zaman ekibin yarısının Gitflow, yarısının GitHub Flow zannettiği yamalı bir şey çıkar. İki modelden birini doğru uygulamak, üçüncü bir model uydurmaktan her zaman ucuzdur.

Workflow, yazılımın yaşam döngüsünün şeklidir

Branch stratejisi bir özelliğin doğduktan kaç gün sonra prod’a vardığını, hangi koridorlardan geçtiğini, nasıl bir bakım hattında yaşlandığını belirleyen şeydir. Yani yazılımın yaşam döngüsünü — kodun değil, kararın hızını — şekillendirir.

İki şirket aynı dili, aynı framework’ü kullansın; biri Gitflow, biri GitHub Flow seçtiyse aynı özelliği prod’a çıkarma süreleri tek başına bu kararla 3’e katlanır. Bu yüzden branch stratejisi tooling sorusu değil, ürün sorusudur.

İkisi de yetmediğinde

Bazı ekiplerde deploy ritmi öyle hızlanır ki — günde 5+ deploy — GitHub Flow’un kısa ömürlü branch’leri bile bir sürtünme kaynağı olmaya başlar. O eşikten sonra ben trunk-based’e geçiyorum: branch’ler saatlerle ölçülür, yarım iş feature flag arkasında kodda yaşar.

Üçü de farklı bir tempo için tasarlanmış araçlar. Hangisinin sizi rahat ettireceği, yazdığınız kod ile prod’unuz arasındaki mesafenin kaç saat olmasını istediğinize bağlı.

Karar değişir, doğrudur

Bugünkü ürün şeklinizi 2 yıl sonraki ekibinize dayatmak en pahalı hatalardan. Üç sinyalden biri değiştiğinde — sürüm sayısı çoğaldı, müşteri tipi değişti, deploy frekansı 10’a fırladı — branch stratejisini de yeniden açın. Workflow bir kez seçilen değil, ürün değiştikçe yeniden değerlendirilen bir karardır.

Branch stratejisinin günlük operasyonel yanını — workflow seçimi, rebase ile tarihçe hijyeni, bisect ve reflog, --force disiplini — bir bütün hâlinde Production’da Git: Senior’ın Pratik Rehberi yazısında topladım. Bu seçim, o resmin yalnızca giriş kapısı.

Gitflow ile GitHub Flow arasındaki seçim, “hangisi modern” değil “ürün şekliniz hangisini doğal kılıyor” sorusudur. Yanlış cevap, yıllarca her PR’da iki dakika ödenir.

Git workflow’unu ürüne göre seçin; ürünü workflow’a göre değil.

Projelere Neden Modüler Monolit ile Başlıyorum?

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 23 May 2026 00:00:00 GMT

Yeni bir projenin ilk gününde, mimari tahtasının başında biri mutlaka şu soruyu soruyor: “Servisleri nasıl böleceğiz?” Cevabım çoğu zaman aynı: “Şimdilik bölmüyoruz.”

Bu bir erteleme ya da üşengeçlik değil. Neredeyse her yeni projeye bilinçli olarak modüler monolit ile başlıyorum: tek codebase, tek deploy, tek veritabanı — ama içeride net modül sınırları. Bu yazı neden böyle yaptığımın gerekçesi.

”Modüler monolit” ne demek?

Üç şeyi birbirinden ayırmak gerekiyor:

Klasik monolit — sınır yok. Her şey her şeye erişir, zamanla “big ball of mud”.
Mikroservisler — sınır var, ama sınır aynı zamanda bir network çağrısı.
Modüler monolit — sınır var, ama sınır process içinde; bir method çağrısı.

Asıl mesele şu: modül sınırı çizmek ile onu ayrı bir servise koymak iki ayrı karardır. Mikroservis mimarisi bu ikisini tek bir karara sıkıştırıyor — sınır demek, otomatik olarak ayrı deploy, ayrı veritabanı, network demek. Modüler monolit bu ikisini ayırıyor: sınırı bugün çizin, dağıtımı gerçekten gerekince yapın.

Sınırlar kodda nasıl görünüyor

Laravel tarafında kullandığım yerleşim kabaca şu:

app/
└── Modules/
    ├── Billing/
    │   ├── Domain/            # entity'ler, value object'ler — modüle özel
    │   ├── Application/       # use-case'ler
    │   ├── Infrastructure/    # repository, dış servis adaptörleri
    │   └── BillingApi.php     # modülün TEK public yüzeyi
    ├── Catalog/
    └── Notification/

Kural basit: bir modül, başka bir modülün yalnızca *Api.php sınıfını çağırır. Domain ve Infrastructure içindeki her şey o modüle özeldir — dışarıdan görünmez.

İkinci kural veritabanında: bir modül, başka bir modülün tablosuna doğrudan SELECT atmaz, foreign key bağlamaz. Catalog’un bir faturaya ihtiyacı varsa BillingApi’den geçer, billing_invoices tablosuna el uzatmaz. Bu disiplin sıkıcı görünüyor — değeri tam da burada.

Neden buradan başlıyorum

Beş somut sebep:

Sınırı yanlış çizme maliyeti düşük. Projenin ilk haftasında domain’i tam anlamıyorsunuz. Modül sınırı yanlış çıkarsa, modüler monolitte bunu düzeltmek bir refactor — IDE’nin “move” komutu ve birkaç saat. Aynı hatayı mikroserviste düzeltmek iki servisin API kontratını, iki deploy pipeline’ını ve canlı veri taşımayı içeriyor. Erken dönemde sınırlar kesinlikle yanlış olacak; ucuz düzeltilebilen yapıyı seçin.
Tek transaction. İki modülü tek bir DB transaction’ı içinde tutarlı güncelleyebiliyorum. Mikroserviste aynı şey saga, outbox, eventual consistency demek. Bunlar gerçek araçlar — ama gerçekten gerekene kadar ertelenmesi gereken bir karmaşıklık.
Operasyonel yük neredeyse sıfır. Tek deploy, tek log akışı, izlenecek tek hedef. Servisler arası retry, distributed tracing, kontrat versiyonlama — bunların hiçbiri yok. Üç kişilik bir ekip için bu, haftada kazanılan günlerdir.
Refactor araçları çalışıyor. “Rename”, “find usages”, statik analiz — hepsi process sınırı içinde işliyor. Bir method çağrısını compiler doğruluyor; bir network kontratını kimse doğrulamıyor.
Mikroservise geçişi kolaylaştırıyor. En sık atlanan nokta bu: sınırlar zaten net olduğu için, bir modülü ayrı servise çıkarmak ileride mekanik bir iş haline geliyor. Modüler monolit, mikroservislerin alternatifi değil; doğru yapıldığında onlara giden en ucuz yol.

Sınırı ayakta tutan disiplin

Modüler monolitin tek zayıf noktası şu: sınırlar zorla uygulanmıyorsa, yapı sessizce çürüyüp eski tip monolite döner. “Sadece bu sefer” diye atılan her doğrudan çağrı bir delik açar.

Sınırı ayakta tutan dört pratik:

Statik bağımlılık kuralları. deptrac ya da benzeri bir araçla “Catalog, Billing’in Domain katmanına erişemez” kuralını CI’da zorunlu kılın. İhlal, build’i kırsın.
Tek public yüzey. Her modülün dışarı açık API’si tek bir sınıf; geri kalan her şey internal. Görünürlüğü dilin izin verdiği ölçüde daraltın.
Veri sınırı. Modüller arası ilişki foreign key ile değil, ID + public çağrı ile kurulur.
Review’da tek soru. Kod incelemesinde sorulacak en önemli soru: “Bu değişiklik bir modül sınırını izinsiz geçiyor mu?”

Sınır CI tarafından zorlanmıyorsa, elinizde modüler monolit değil, sadece klasör isimleri düzgün bir monolit var. Bütün değer disiplinde.

Ne zaman ayrı servise bölüyorum?

Modülü ayrı bir servise çıkarmak için ölçülmüş bir sebep beklerim. Dört sinyalden biri yeterli:

Ölçeklenme profili ayrışıyor. Notification modülü CPU-bound, geri kalan sistem I/O-bound. Birini diğerinden bağımsız ölçeklemek istiyorsam, ayırmak artık karşılığını veriyor.
Sahiplik ayrışıyor. Modül ayrı bir ekibin sorumluluğuna geçti ve bağımsız deploy artık teknik değil, organizasyonel bir ihtiyaç.
Farklı bir runtime gerekiyor. Ağır bir hesaplama Go’da çok daha ucuz, geri kalan PHP’de kalmalı.
Hata izolasyonu zorunlu. Bir modülün çökmesi gerçekten geri kalan sistemi düşürmemeli ve bunu process içinde garanti edemiyorum.

Bunlardan biri ölçülerek ortaya çıkana kadar bölmek erken optimizasyondur. Bu, boring architecture savunmamın doğrudan uzantısı: karmaşıklığı, onu zorlayan kanıt gelene kadar erteleyin. Sınırlar baştan net olduğu için, o gün geldiğinde bölme işi korkutucu bir göç değil, planlı bir adım oluyor.

Mikroservisler bir mimari tarzı değil, bir dağıtım kararıdır. O kararı projenin ilk gününde — domain hakkında en az şey bildiğiniz anda — vermek için hiçbir sebep yok. Modüler monolit bana o kararı erteleme ve zamanı geldiğinde hazır olma lüksünü veriyor.

Sınırları erken çizin, dağıtımı geç yapın.

Trunk-Based Development'a Ne Zaman Geçiyorum?

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 23 May 2026 00:00:00 GMT

Cuma öğleden sonra prod’a 6’ncı deploy gidiyor. release/2026.05 branch’inden alınan hotfix develop’a geri merge edilirken bir önceki hotfix ile çakışıyor. Üç kişilik bir kanal açılıyor, on dakika konuşuluyor, kimse “bu aslında trivial bir conflict” diye düşünmüyor — çünkü bu hafta dördüncüsü.

Sahne tanıdık geliyorsa, branch stratejiniz deploy temponuza yetişemiyor demektir.

Trunk-based ne, bir cümlede

Tek bir uzun ömürlü branch (main ya da trunk), ömrü saatlerle — en fazla 1–2 günle — ölçülen feature branch’ler ve her merge’in prod’a gidebilecek kadar yeşil tutulduğu bir tempo. Bitmemiş özellikler kodda yaşar, kullanıcıya feature flag’le açılır.

Daha fazlası yok — release/* branch’i yok, develop branch’i yok, sürüm numarasına bağlı uzun yaşayan dallar yok.

”Yüksek frekans” derken

Concrete olmazsa anlamsız: trunk-based’i savunduğum projelerin ortak özelliği günde 3–10 deploy. Haftada 1 deploy yapan bir ekibin trunk-based’e geçmesi için zorlayıcı bir sebep yok — Gitflow ya da GitHub Flow o ritimde sorunsuz çalışıyor.

Eşik bende net: deploy frekansı haftada 5+ olduğunda release branch bir “düzen” değil, bir engel olmaya başlıyor.

Release branch yüksek frekansta neden kırılıyor

Üç gerçek mekanizma:

Merge sürtünmesi lineer büyümez. İki branch ne kadar uzun yan yana yaşarsa, çakışma olasılığı her gün artar. Haftalık release döngüsünde bu görünür değil; günlük döngüde her merge bir mini drama.
Hotfix yolu paralel bir tarih yaratır. hotfix/* → main → geri develop’a port. Bu portu unutmak en sık görülen prod bug kaynağı; yüksek frekansta unutmamak istatistiksel olarak imkânsız.
Review ile deploy arasındaki mesafe açılır. Bir PR’ın “merge’lendi” anı ile prod’a düştüğü an arasında günler varsa, code review aslında prod’u değil bir staging’i değerlendirir. İki ortam aynı şey değildir.

Bu workflow’un asıl maliyeti: disiplin

Trunk-based, “branch silelim” değildir. Bir kod parçasının doğumdan emekliliğe yolculuğunu — yazılımın yaşam döngüsünü — daha sıkı bir tempoya bağlayan bir disiplindir. Bu disiplin olmadan yapılan trunk-based, yalnızca daha hızlı kırılan bir prod demektir.

Şunlar olmadan denemeyin:

Yeşil trunk, sözleşme seviyesinde. Kırık trunk = herkesin bloklandığı an. Bunu garantileyen CI yoksa (hızlı, güvenilir test piramidi + zorunlu PR check’leri), trunk-based bir ütopya.
Feature flag altyapısı. Yarım bitmiş özelliklerin koda girip kullanıcıya kapalı kalması bu modelin temeli. Boolean flag’den profile-based rollout’a kadar bir feature flag disiplini şart.
Hızlı pipeline. Merge’den prod’a 30 dakika geçiyorsa, “her merge prod’a gidebilir” iddiası teorik. 5–10 dakika aralığı pratik eşik.
Kısa ömürlü branch kültürü. PR’ı 4 günde merge etmek trunk-based değil, gizli Gitflow. Branch açıldığı gün ya da ertesi gün kapanmalı.

Bu dördü oturmadıysa, ekibe trunk-based dayatmak prod’u hızlandırmaz — yalnızca prod kazalarını hızlandırır.

”Code review yavaşlatır” diye duyacaksınız

Yavaşlatmaz, parçalar. Trunk-based PR’lar tasarımı gereği küçüktür — 200–400 satır, tek bir mantıksal değişiklik. Bu boyutta review 60–90 dakikadır. 2.000 satırlık bir PR’ı kimsenin gerçekten okumadığını bilen herkes, küçük PR’a geçişin gerçek kazancını görür.

Küçük PR + feature flag, “bu özellik prod’da görünür mü” sorusunu “bu kod prod’da derlenir mi” sorusundan ayırır. İkisi farklı kararlardır; trunk-based bu ayrımı zorunlu kılar.

Geçmediğim durumlar

Aynı önlem listesinin tersi geçerli. Trunk-based’e geçmediğim sahneler:

Regüle sektörde zorunlu pre-prod sign-off. Bir release’in compliance kapısından geçmesi gerekiyorsa, release branch teknik değil hukuki bir zorunluluk. Trunk-based onu kaldıramaz.
Paralel sürüm bakımı. Aynı anda 3.x ve 4.x desteklenecekse — packaged ürün, SDK, on-prem dağıtım — Gitflow’un sürüm hattı doğal cevaptır.
CI olgunluğu yok. Trunk-based, kırık ana branch’in maliyetini ekibe yıkar. CI yeşilini garantileyemeyen bir ekipte bu maliyet günde 1–2 saat boşa giden zaman olarak ödenir.
3 kişiden küçük ekip, haftada 1 deploy. Yatırım amorti olmaz; mevcut sıkıntınız trunk-based ile çözülmez çünkü zaten yoktur.

Geçişi ölçtüğüm metrikler

“İyi gidiyor” hipotez değil, ölçülmüş olmalı. Trunk-based’in çalışıp çalışmadığını şu üç metrikten okuyorum:

Lead time for changes — commit’ten prod’a kadar geçen p50 süre. Hedefim < 1 saat.
Change failure rate — prod’a giden değişikliklerin yüzde kaçı rollback ya da hotfix gerektiriyor. Hedefim < %15.
Mean time to restore — bozulan bir şey kaç dakikada düzeliyor. Hedefim < 30 dakika.

Bu üçü kötüye giderse trunk-based’i bırakmadan önce CI ve flag disiplinini gözden geçiriyorum — sebep neredeyse her zaman orada.

Workflow tek başına gümüş kurşun değil

Trunk-based, Gitflow ya da GitHub Flow — hiçbiri tek başına prod’unuzu düzeltmiyor. Production’da branch stratejisi, code review temposu, deploy otomasyonu ve rollback hazırlığı birlikte çalışan bir bütün. Bu bütünün branch stratejisi ve commit/review hijyeni tarafını daha önce Production’da Git: Senior’ın Pratik Rehberi yazısında derlemiştim; trunk-based o resimde temponun en hızlandığı uçtur.

İki uç arasında nereye düştüğünüze karar vermek için, Gitflow ile GitHub Flow arasındaki seçimi ayrı bir yazıda anlattım.

Trunk-based bir araç değil, bir tempo kararıdır. Deploy frekansınız hangi tempoya oturuyorsa workflow’unuz da oraya oturmalı — tersi değil.

Workflow’u modaya göre değil, prod’un nabzına göre seçin.

Veri Yoğunluklu Sistemlerde Ölçek Kırılma Noktaları

info@muhammetsafak.com.tr (Muhammet Şafak) — Wed, 20 May 2026 00:00:00 GMT

Web backend’lerinin çoğu compute-intensive değil, data-intensive’dir. Darboğaz nadiren CPU’nun bir şeyi hesaplaması olur; neredeyse her zaman veriyi bir yerden bir yere taşımak, saklamak ve tutarlı tutmaktır. Boring architecture — tek VPS, paylaşılan PostgreSQL, paylaşılan Redis — bu yükün şaşırtıcı bir kısmını taşır.

Ama veri yükü altında bu mimari kademeli olarak yavaşlamaz. Ayrık noktalarda, hem de tahmin edilebilir bir sırayla kırılır. Bu yazı o noktaları haritalıyor: her birini hangi sinyal haber verir, sonraki adım nedir ve o adımın maliyeti nedir?

Tek bir kuralı baştan söyleyeyim: bu adımları sırasıyla yapın. Her adım size zaman kazandırır ve karşılığında operasyonel ağırlık ekler. 4. adımı 1. adımdan önce yapmak, hiçbir şey çözmeden karmaşıklık vergisi ödemektir.

Veri yoğunluğu hangi eksende kırılır

“Ölçeklenme” tek bir sayı değildir. Request sayısı bir eksen, veri hacmi bambaşka bir eksen. Bir sistem dakikada 50 request alıp yine de veri tarafından boğulabilir; bir başkası saniyede 5.000 request’i rahat karşılarken veri katmanı el değmemiş durur.

Veri yoğunluklu sistemleri kıran asıl eksenler şunlar:

Working set / RAM oranı — sık erişilen verinin RAM’e sığıp sığmadığı.
Okuma / yazma oranı — yükün hangi tarafa baskın olduğu.
Tek tablo boyutu — tek bir ilişkinin index ve vacuum davranışını bozacak kadar büyümesi.
Yazma throughput’u — tek primary’nin saniyede absorbe edebileceği commit sayısı.
Tutarlılık gereksinimi — verinin ne kadar bayat okunabileceği.

Bu eksenlerin hepsi aynı anda kırılmaz. İyi haber bu: çünkü hepsini aynı anda çözmeniz gerekmiyor. Mimari kararı, “hangi eksen önce kırılacak” sorusuna dürüst cevap vermekle başlar — varsayımla değil, ölçümle.

Başlangıç durumu

Kırılma noktalarını konuşmadan önce kırılacak şeyi tarif edeyim. Laravel production stack yazısındaki kurulumun veri katmanı şuna benzer:

   PHP-FPM ──┬──► pgBouncer ──► PostgreSQL 16
             │                  (tek primary)
             │
             └──► Redis 7
                  (cache · session · lock)

Tek primary, önünde pgBouncer ile bağlantı havuzu. Redis cache, session ve lock taşıyor. Bu kurulum, veritabanı birkaç on GB’ta kaldığı ve working set RAM’e sığdığı sürece, dakikada binlerce request’e kadar hiç şikâyet etmeden çalışır. Asıl mesele: çalışmayı ne zaman bırakacağı.

Kırılma noktası 1 — Working set RAM’e sığmıyor

Veri yoğunluğunun ilk ve en sık kırılma noktası budur. PostgreSQL sık erişilen sayfaları shared_buffers’ta, ötesini işletim sisteminin page cache’inde tutar. Sıcak veri — yani working set — bu iki katmana sığdığı sürece okumalar RAM hızındadır. Sığmadığı an her sorgu rastgele disk I/O’suna düşer ve p95 gecikme aniden, kademesiz biçimde tırmanır.

Sinyal! Cache hit ratio’nun düşmesi. Bunu tahmin etmeyin, ölçün:

SELECT
  sum(blks_hit) * 100
    / nullif(sum(blks_hit) + sum(blks_read), 0) AS cache_hit_ratio
FROM pg_stat_database;

Sağlıklı bir OLTP sisteminde bu oran %99’un üzerindedir. %95’e doğru düşmeye başladıysa working set artık shared_buffers’a sığmıyor demektir — ama bu yalnızca birinci katman: blks_hit sadece PostgreSQL’in kendi buffer cache’indeki isabetleri sayar, işletim sisteminin page cache’inden dönen bir sayfa burada blks_read olarak görünür. Bu yüzden oranı disk read IOPS ile birlikte okuyun: oran düşerken IOPS da sürekli yükseliyorsa working set gerçekten RAM’i taşırıyordur. pg_statio_user_tables’ta belirli tablolarda heap_blks_read’in heap_blks_hit’e yaklaşması bunu hangi tabloların yaptığını gösterir.

Ne yapılır? Sırasıyla:

Önce index disiplini. Çoğu “RAM yetmiyor” vakası aslında “gereksiz veri okunuyor” vakasıdır. Eksik index yüzünden sequential scan yapan bir sorgu, working set’i olduğundan kat kat büyük gösterir. pg_stat_user_tables’ta seq_scan sayısı yüksek olan büyük tabloları bulun.
Sonra ölü veriyi ayırın. Sıcak ve soğuk veri aynı tabloda yaşıyorsa working set yapay olarak şişer. Üç yıllık kapalı kayıtla bu haftanın aktif kayıtları aynı heap’te durmak zorunda değil.
En son vertical scale. RAM eklemek bir kez yapılır, ucuzdur ve karmaşıklık eklemez. Working set’in birkaç katı RAM’iniz olsun. Bu, alınabilecek en sade ölçek hamlesidir — utanılacak bir şey değil, ilk tercihtir.

Maliyet. Index bakımının her yazıya eklediği maliyet ve daha büyük bir VPS’in aylık farkı. İkisi de küçük. Bu yüzden 1. kırılma noktası en ucuz çözülenidir — ve bu yüzden ilk sıradadır.

Kırılma noktası 2 — Okuma yükü tek primary’yi doyuruyor

Working set RAM’e sığıyor ama primary yine de doluyor. CPU sürekli yüksek, sorgular kuyrukta bekliyor ve yük ezici biçimde okuma tarafında. Rapor sayfaları, listeleme endpoint’leri, arama — hepsi aynı primary’den okuyor.

Sinyal! Primary’de CPU sürekli yüksekken yazma oranı düşük kalıyor. pg_stat_statements’ta toplam süreyi SELECT’ler domine ediyor. pgBouncer’da cl_waiting sayacı sıfırdan kalkmış — yani client’lar bağlantı için sıraya giriyor.

Ne yapılır? Bir read replica. PostgreSQL’in streaming replication’ı ile primary’nin yanına hot standby bir kopya kurun, okuma trafiğini oraya yönlendirin. Laravel bunu connection ayrımıyla doğal destekler:

// config/database.php
'pgsql' => [
    'driver'  => 'pgsql',
    'read'  => ['host' => ['10.0.0.2']],   // replica
    'write' => ['host' => ['10.0.0.1']],   // primary
    'sticky' => true,
    // ...ortak ayarlar
],

sticky => true kritik. Bir request içinde yazma yaptıysanız, aynı request’teki sonraki okumalar primary’ye gider — kullanıcı kendi yazdığı veriyi bayat görmez. Replica’nın kendi pgBouncer havuzu olur; primary’ninkinden ayrı.

Maliyet. Replication lag. Replica primary’nin birkaç milisaniye — yük altında birkaç saniye — gerisindedir. Yani read-after-write consistency’yi kaybedersiniz, sticky’nin kurtardığı request sınırının dışında. Lag’i izlemek artık bir operasyon kalemidir:

SELECT client_addr, state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes
FROM pg_stat_replication;

İkinci maliyet: her sorgunun “bu bayat veri okuyabilir mi” sorusuna cevap vermesi gerekir. Çoğu listeleme/rapor için cevap “evet”. Bakiye, stok, yetki kontrolü için cevap “hayır” — onlar primary’de kalır. Bu sınıflandırma artık mimarinin parçasıdır ve dokümante edilmesi gerekir.

Not: Read replica yazma kapasitesine hiçbir şey katmaz. Aynı yazmalar replica’da da tekrar oynanır. Replica, okuma yükü problemini çözer — yazma yükü problemini değil. İkisini karıştırmak en pahalı yanlış kırılma noktasıdır.

Kırılma noktası 3 — Tek tablo fazla büyük

Veritabanı toplamda makul, ama tek bir tablo onlarca-yüz milyon satıra ulaşmış. Genelde append ağırlıklı olanlar: events, audit_log, notifications, zaman serisi ölçümler. Bu tablo artık kendi başına bir problem.

Sinyal! O tabloda autovacuum yetişemiyor — pg_stat_user_tables’ta n_dead_tup sürekli yüksek ve last_autovacuum eskimiş. Index’ler şişiyor, tek satır güncellemesi bile yavaşlıyor. Eski veriyi DELETE etmek saatler sürüyor ve arkasında devasa bir vacuum borcu bırakıyor.

Ne yapılır? O tabloyu partition’lara bölün. Append ağırlıklı veride doğal anahtar zamandır:

CREATE TABLE events (
    id          bigserial,
    occurred_at timestamptz NOT NULL,
    payload     jsonb       NOT NULL
) PARTITION BY RANGE (occurred_at);

CREATE TABLE events_2026_05 PARTITION OF events
    FOR VALUES FROM ('2026-05-01') TO ('2026-06-01');

Bunun kazandırdığı:

Partition pruning — occurred_at filtreli sorgular sadece ilgili partition’lara dokunur.
Ucuz silme — eski veriyi atmak DELETE değil, DROP TABLE events_2026_01. Saniyeler, vacuum borcu yok.
Sınırlı vacuum — autovacuum her partition’la ayrı ayrı, küçük parçalar hâlinde uğraşır.

Aylık partition oluşturmayı pg_partman ile otomatikleştirin; elle yönetilen bir partition takvimi unutulmaya mahkûmdur.

Maliyet. Bir gerçek tuzak: partition’lı tabloda primary key, partition anahtarını içermek zorundadır. Yani id tek başına PK olamaz; (id, occurred_at) olur. Bu, başka tablolardan bu tabloya foreign key vermeyi zorlaştırır — append-only log tablolarında zaten genelde istenmez, ama bilerek kabul edilen bir tavizdir. Saf append-only ve “sadece zaman aralığı sorgulanan” tablolarda B-tree yerine BRIN index çok daha küçük ve yeterlidir.

Kırılma noktası 4 — Yazma yükü tek primary’yi doyuruyor

Bu zor olanı. Replica okumayı kurtardı, partitioning tek tabloyu evcilleştirdi — ama primary yazma tarafında doyuyor. Saniyedeki commit sayısı, disk fsync ve WAL throughput’u tavana dayandı. Replica eklemek burada işe yaramaz: aynı yazmalar her replica’da yeniden oynanır.

Sinyal! Primary’de I/O wait yüksek, pg_stat_bgwriter’da checkpoint’ler sıklaşmış, WAL üretim hızı disk’in fsync kapasitesini zorluyor. Yazma gecikmesi okuma yükünden bağımsız tırmanıyor.

Ne yapılır? Burada sihirli tek hamle yok; sırayla şu üçü:

Yazma amplifikasyonunu azaltın. Her index’in her INSERT/UPDATE’e bir maliyeti vardır. pg_stat_user_indexes’ta idx_scan = 0 olan index’leri — yani hiç kullanılmayanları — silin. Sık güncellenen tablolarda fillfactor’ı düşürerek HOT update oranını artırın. Tek tek INSERT yerine batch insert yapın.
Append ağırlıklı veriyi primary’den çıkarın. Yazma yükünün büyük kısmı genelde tek bir kaynaktan gelir: olay logu, metrik, analitik event. Bu veri çoğu zaman ilişkisel bütünlük de istemez. Onu ayrı bir store’a taşımak primary’yi asıl işine — transactional veriye — geri verir.
En son: veri alanını bölün. Hâlâ yetmiyorsa, gerçek bir veri alanı ayrımı (functional sharding) gerekir — ki bu bizi bir sonraki kırılma noktasına götürür.

Maliyet. Bu nokta, boring mimarinin gerçekten zorlandığı yerdir. 1–3 arası noktalar primary’yi tek tutmaya devam ediyordu; buradan sonrası tekillikten ödün vermek demek. Acele etmeyin: çoğu sistem 4. noktaya hiç ulaşmaz, ulaşanların çoğu da aslında 1. noktayı (eksik index, şişmiş working set) atlamış olduğu için erken gelir.

Kırılma noktası 5 — Veri katmanı uygulamadan ayrılmalı

Tek bir uygulama, paylaşılan veritabanında baskın hâle geldi. Yazma yükünü o üretiyor, en büyük tablolar onun, incident’ların kaynağı o. Tek VPS üzerinde çoklu proje mimarisi yazısındaki “büyüme sinyalleri” tam olarak bunu haber verir.

Sinyal! Paylaşılan PostgreSQL’de yükün tek bir database’den geldiği net. O uygulamanın bakım pencereleri diğer projeleri de etkiliyor. Kapasite planı artık “VPS” değil “o uygulama” ekseninde yapılıyor.

Ne yapılır? O uygulamayı kendi veri katmanına taşıyın — ayrı bir PostgreSQL instance’ı, ya kendi sunucusunda ya managed bir serviste. Paylaşılan veritabanından bir uygulamayı çekmek, pgBackRest ile alınan bir yedekten restore + logical replication ile fark kapatma + kısa bir cutover penceresiyle yapılır.

Bu, “her şeyi mikroservise böl” demek değil. Tek bir veri-baskın uygulamayı kendi katmanına almak — diğerleri paylaşılan kurulumda mutlu mesut kalmaya devam ederken. Ayırma kararı veri profiliyle verilir, organizasyon şemasıyla değil.

Maliyet. İkinci bir veritabanı: ikinci bir backup hattı, ikinci bir monitoring hedefi, ikinci bir upgrade takvimi. İki veritabanı arasında artık JOIN yapamazsınız — o sınırı geçen sorgular uygulama katmanında birleşir. Bunlar gerçek maliyetler; tek bir uygulama paylaşılan kurulumu domine ettiği için karşılığında ödenirler, peşin değil.

Yanlış kırılma noktaları

Veri-yükü problemine benzeyen ama olmayan şeyler, en pahalı yanlış dönüşlere yol açar. Sık görülenler:

Görünen	Gerçek	Doğru hamle
”Veritabanı yavaş”	N+1 sorgu — uygulama 200 sorgu atıyor	Eager loading; sorgu sayısını ölç
”Replica lazım”	Tek bir sorguda eksik index	`EXPLAIN ANALYZE`, index ekle
”Sharding lazım”	Replica ve partitioning hiç denenmedi	Önce 2. ve 3. noktayı tüket
”PostgreSQL yetmez, NoSQL’e geçelim”	`jsonb`, partitioning, BRIN hiç kullanılmadı	PostgreSQL’i sonuna kadar kullan
”Yazma yükü var, cache ekleyelim”	Cache yazmayı azaltmaz, okumayı azaltır	Yazma için 4. noktaya bak

Ortak hata kalıbı şu: bir aracın çözdüğü problemle, eldeki problemi karıştırmak. Read replica okumayı ölçekler. Cache okumayı azaltır. Partitioning tek tabloyu evcilleştirir. Bunların hiçbiri yazma throughput’unu artırmaz. Hangi eksenin kırıldığını ölçmeden araç seçmek, yanlış kırılma noktasına yatırım yapmaktır.

Bir de “yeni veritabanı” cazibesi var. Cassandra, MongoDB, ayrı bir Kafka — bunları getirmeden önce PostgreSQL’in jsonb’sini, LISTEN/NOTIFY’ını, declarative partitioning’ini, BRIN index’lerini ve logical replication’ını tükettiğinizden emin olun. Çoğu ekip PostgreSQL’in %20’sini kullanıp “PostgreSQL yetmiyor” sonucuna varır.

Sıra neden önemli

Bu beş nokta bir kontrol listesi değil, bir sıra. Her adım bir öncekinin satın aldığı zamanla ertelenir:

1. Working set / RAM      → index + RAM      (en ucuz)
2. Okuma yükü             → read replica
3. Tek tablo boyutu       → partitioning
4. Yazma yükü             → amplifikasyon + ayrıştırma
5. Veri-baskın uygulama   → ayrı veri katmanı   (en pahalı)

Sırayı atlamak iki yönde de pahalıdır. 1’i atlayıp 2’ye geçerseniz — yani eksik index’i görmezden gelip replica eklerseniz — bayat-veri okuma riskini, replication lag izlemeyi ve fazladan bir sunucuyu, aslında bir CREATE INDEX’in çözeceği problem için satın almış olursunuz. Tersi de geçerli: 4. noktada gerçekten yazma duvarına çarpmış bir sistemi cache ekleyerek “çözmeye” çalışmak, sadece teşhisi geciktirir.

Sade mimarinin gücü, tam da bu kırılma noktalarının görünür ve sıralı olmasıdır. Her adımı bir metrik haber verir, her adımın maliyeti önceden bilinir ve hiçbir adım bir sonrakini zorunlu kılmaz. “Bütün veri katmanı çöktü” senaryosu yerine, “cache hit ratio %96’ya düştü, RAM eklemek lazım” senaryosunu yaşarsınız.

Bu yaklaşımın gerçekten bittiği yer de bellidir: tek bir büyük makinenin fsync kapasitesini aşan sürdürülebilir yazma throughput’u, ya da coğrafi olarak dağıtık low-latency gereksinimi. Oraya ulaşan bir sistem zaten bunu finanse edecek bir iş modeline sahiptir — ve o noktada karmaşıklık artık bir borç değil, ödenmiş bir bedeldir. Ondan önce değil.

Neden Boring Architecture'ı Tercih Ediyorum

info@muhammetsafak.com.tr (Muhammet Şafak) — Fri, 15 May 2026 00:00:00 GMT

Bir genç mühendis bana “neden Laravel ile uğraşıyorsun, X yeni framework daha hızlı” diye sorduğunda iç çekerek başlayan bir konuşma açıyorum. Cevap “Laravel daha iyi çünkü Y” değil. Cevap şu: “Her ekip için sınırlı bir karmaşıklık bütçesi var, ben onu daha önemli yerde harcamayı tercih ediyorum."

"Boring” ne demek?

Dan McKinley’nin meşhur “Choose Boring Technology” yazısı bu tabiri popülerleştirdi. “Sıkıcı” burada kötü değil — öngörülebilir, iyi belgelenmiş, hata durumunda Stack Overflow’da on yıl önce verilmiş cevabı bulunabilen anlamına geliyor.

Boring stack benim için şunlar:

PHP + Laravel ya da Symfony
PostgreSQL
Redis
Nginx
Linux + systemd + Supervisor

Yeni bir tane ekleyince — diyelim RabbitMQ — onu da boring kategorisine sokmak için 12–18 ay üretimde aktif kullanmam gerekiyor. O zamana kadar deneysel, kuşkulu.

”Innovation token” kavramı

Aynı yazıda McKinley innovation token diye bir mecaz kullanıyor: her ekibin harcayabileceği sınırlı sayıda inovasyon token’ı var. Yeni bir dil seçmek bir token. Yeni bir veritabanı seçmek bir token. Yeni bir deployment platformu bir token.

Tipik küçük bir ekip için bütçe: 3 token.

Bunları:

Yeni bir programlama dili
Yeni bir veritabanı türü
Yeni bir mesajlaşma sistemi
Yeni bir orchestration platformu

şeklinde harcadığınızda, ürünün kendisine — gerçekten değer üretecek karmaşıklığa — ayıracak token kalmıyor.

Üç token’ımı nerede harcıyorum?

Çoğu projede şu üçünü harcıyorum:

Domain karmaşıklığı. İş kuralları, dağıtık iş akışları, eventual consistency gibi şeyler bütçe yer çünkü iş gerektiriyor.
Yeni bir altyapı parçası (örn. message broker eklemek, search engine eklemek). Yılda en fazla bir kez.
İlginç bir denemenin küçük bir bölümünde — bir özelliği yeni bir araçla yapıp ne öğrendiğimizi görmek için. Çoğu zaman tekrar atılır.

Geri kalan her şey kanıtlanmış.

Birinci dünya sorunu mu?

Hayır. Boring tech savunması özellikle kaynaklarımız sınırlıyken önemli. Büyük şirketler “tüm akışları GraphQL’e taşınıyoruz” derken 200 mühendisin bir kısmı bu işle ilgileniyor. Sizin 3 kişilik ekibinizin bunu yapması = 3 ay özellik geliştirmemek.

”Ama bu altyapı eski”

PostgreSQL 1996’dan beri var. PHP 1995’ten. Nginx 2004’ten. Redis 2009’dan.

“Eski” doğru kelime değil — olgun doğru kelime. Olgun yazılım:

Edge case’leri keşfedilmiş ve düzeltilmiş.
Hata mesajları Google’a yazılınca cevap bulunuyor.
Ekibin yeni katılan üyesi ilk gününde productive olabiliyor.
“Bu bug’ı kim yaratmış” sorusu kütüphane sürümünüze çıkmıyor.

İstisnalar neler?

Bir özellik kanıtlanmış araçla yapılamıyorsa. Örnek: gerçek zamanlı collaborative editing için CRDT (Conflict-free Replicated Data Type) — bu mature bir alan değil, sıfırdan yazmak istemezsiniz.
Ekipte herkes yeni araçla deneyimli. Eğer 5 mühendis Go ile yıllardır yazıyorsa, PHP’ye zorlamak yanlış.
Performans gereksinimi açık ve ölçülmüş. “Daha hızlı olur” hipotezi değil, “şu noktada darboğaz var, X dili çözüyor” demonstrasyonu.

Sonuç

Yeni teknoloji yapmak heyecanlı. Eski teknoloji çalıştırmak sıkıcı. Bu ikisi arasındaki fark, üretimde 2 yıllık bir ürün ile 6 aylık bir ürün arasındaki fark. Hangi tarafı önemsiyorsanız ona göre seçim yapın — ama farkı bilerek yapın.

Boring tech bir korkaklık değil, bir bütçe kararı. Bütçenizi daha değerli problemlere ayırın.

Shared Redis Kullanırken Namespace İzolasyonu

info@muhammetsafak.com.tr (Muhammet Şafak) — Tue, 12 May 2026 00:00:00 GMT

VPS başına bir Redis çalıştırmak küçük-orta projelerde gayet makul bir karar. Sorun, birden çok uygulama aynı instance’ı paylaşmaya başladığında ortaya çıkıyor: bir projenin users anahtarı diğerinin users anahtarını eziyor, biri FLUSHALL çağırınca herkes çuvallıyor.

Çözüm yeni bir Redis kurmak değil; namespace disiplini.

Üç katmanlı bir anahtar şeması

Üretimde şu kalıbı kullanıyorum:

<env>:<app>:<bounded-context>:<key>

Örnek:

prod:billing:invoice:42
prod:auth:session:1c2f...
staging:notify:queue:retry

Bu üçlüye sahip olmak iki şeyi getiriyor:

Aramada netlik. redis-cli --scan --pattern 'prod:billing:*' ile sadece bir projenin anahtarlarını görebiliyorum.
Yanlışlıkla silmeyi zorlaştırma. FLUSHDB yerine redis-cli --scan --pattern 'staging:*' | xargs redis-cli DEL yazarken iki kez düşünüyorum.

Logical DB’lere güvenmeyin

Redis’in 0-15 arası logical DB’leri var ama tek kelimeyle: kullanmayın. Üç sebep:

SELECT komutu sadece o bağlantı için scope’lu — connection pool’da kaos.
Bazı kütüphaneler MULTI/EXEC blokları içinde DB switch’i desteklemiyor.
Redis Cluster logical DB’leri zaten desteklemiyor; yarın cluster’a geçerseniz tüm varsayımınız çöker.

Namespace prefix’i öğrenip uygulamak tek yöntemdir.

Connection-level izolasyon

Laravel kullanıyorsanız config/database.php içinde her uygulama için ayrı bir Redis bağlantısı tanımlayın ve prefix ile namespace’i bağlantıya gömün:

'redis' => [
    'billing' => [
        'host' => env('REDIS_HOST'),
        'password' => env('REDIS_PASSWORD'),
        'port' => env('REDIS_PORT', 6379),
        'database' => 0,
        'prefix' => 'prod:billing:',
    ],
    'auth' => [
        // ...
        'prefix' => 'prod:auth:',
    ],
],

Artık Redis::connection('billing')->set('invoice:42', ...) çağrısı otomatik olarak prod:billing:invoice:42 yazıyor. Geliştirici yanlışlıkla namespace yazmayı unutursa bile sistem kendini koruyor.

Tehlikeli komutları kapatın

redis.conf içinde production’da şu komutları yeniden adlandırmak veya kapatmak iyi bir fikir:

rename-command FLUSHDB ""
rename-command FLUSHALL ""
rename-command KEYS ""

KEYS özellikle önemli — tarama boyunca event loop’u bloke ediyor ve diğer tüm istemciler sırada bekliyor. Redis’in kendi dokümantasyonu 1 milyon anahtarlı bir veritabanını giriş seviyesi bir dizüstünde yaklaşık 40 ms’de tarıyor, yani 100k key’li bir instance’da milisaniyeler mertebesindesiniz — ama maliyet anahtar sayısıyla birlikte büyüyor, milyonlarca anahtarlı instance’larda duraklama canınızı yakacak kadar uzuyor. Yerine SCAN kullanılması zorunlu olmalı.

Ne zaman bu kalıbı bırakırsınız?

Üç sinyalden biri varsa ayrı Redis instance’larına geçin:

Bir projenin trafiği diğerlerinin gecikmesini ölçülebilir biçimde etkiliyor.
Bir proje persistent storage istiyor (RDB/AOF), diğerleri cache-only.
Bir proje farklı bir Redis sürüm/feature ihtiyacı duyuyor.

Bunlardan önce şu basit kuralı aklınızda tutun: bir prefix yazmak, yeni bir process başlatmaktan ucuzdur.

AI-Assisted Engineering Workflow'um

info@muhammetsafak.com.tr (Muhammet Şafak) — Sun, 10 May 2026 00:00:00 GMT

AI coding agent’larıyla 2 yıldır günlük çalışıyorum. İlk yıl naif kullandım, ikinci yıl disiplin geliştirdim. Bu yazı disiplinin somut hali.

Sayısal olarak ne kadar hızlandığım önemli değil — önemli olan kodun kalitesi azalmadı. Aksine, kod tabanına gelen junior’ların ürettiği bug’lardan daha azını ürettim. Bu bir başarı değil, ajan kullanmamayı öneren bir reklam değil — ne işe yaradığına dair bir gözlem.

1. Ajana plan yaptırma, onayla, sonra yazdır

“Bana auth modülü yaz” demek = kontrolsüz. İşe yarayan akış:

“Auth modülü için bir plan çıkar. Endpoints, DB tabloları, edge case’ler.”
Planı oku, sor, düzelt.
“Plana göre yaz” — ama büyük modüllerde adım adım.

Onaylı planın olmadan kod yazma izni verme. Her zaman.

2. Sınırlı erişim ver

Bir ajanın rm -rf çalıştırabilmesi gereksiz. Sandbox tercih:

Read-only filesystem mount’lar dışında.
Network erişimi sadece belirli endpoint’lere.
Production secrets’a erişim asla. Local mock veya scrubbed copy.

Bu “ajan kötü niyetli” varsayımı değil, “hata yapabilir” varsayımı.

3. Test ettir, çalıştır, geri al

Ajan kod yazdı. Şimdi:

Test yazdır (ya da var olan testleri çalıştır).
Testi çalıştır. Geçtiği iddiası yetmez — gerçekten gör.
Manuel smoke test yap. Ajanın iddialarına değil, gözüne güven.
Şüphe varsa git checkout . — tekrar dene.

Ajanın özeti gerçek değil. Yalan söylemiyor — sadece kendi çıktısının iyi olduğunu varsayıyor. Doğrulama insan işi.

4. Code review aşamasını atlama

Ajanın ürettiği kod, junior bir mühendisin ürettiği kod gibi gözden geçirilmeli. “Ajan zaten kontrol etmişti” yanılgısına düşme. Özellikle:

Güvenlik. SQL injection, XSS, auth bypass.
Performance. N+1 query’ler, gereksiz cache invalidation.
Boundary condition’lar. Boş input, çok büyük input, Unicode.

Bunları yakalamak için statik analiz iyi, ama insan gözü vazgeçilmez.

5. Bağlamı saklı tut

Ajanın “geçmişe sahip olmadığını” unutma. Her oturumda hangi karara neden vardığını anlatmak gerekiyor. Bunu otomatikleştirmek için:

Repo’da CLAUDE.md veya .ssot/ gibi yerlerde durumun anlık özetini tutuyorum.
Önemli kararları oraya yazıyorum: “PostgreSQL kullanıyoruz çünkü…, Redis cache-only modunda çalışıyor çünkü…”.
Ajan oturumun başında bunu okur, daha tutarlı kararlar verir.

6. Ajanı tek mühendise yerleştirme

Bir ajanı senior bir mühendis yerine koymak yanlış. Ajanı bir senior mühendisin uzantısı olarak kullanmak doğru. Junior mühendislere doğrudan “ajan’a yaptır” demek genellikle felaket — çünkü:

Ajanın çıktısını eleştirel okumayı bilmiyorlar.
Doğru soruyu sormayı henüz öğrenmediler.
“Çalışıyor” ile “doğru çalışıyor” arasındaki farkı henüz hissedemiyorlar.

Junior’a verilecek görev, ajanı denetlemek olabilir — ama yönetmek değil.

7. Üretime ulaşan kodun her satırından sorumlu sensin

Bu en önemlisi. Ajanın yazdığı bir SQL injection açığını sen merge ettiysen, sorumluluk senin. “AI yazdı” ifadesi PR review’unda bahane değil.

Pratik karşılığı: ajanın ürettiği her şeyin gerçekten okuduğun, anladığın, gerekirse savunabildiğin kod olduğundan emin olana kadar merge etme.

Sonuç

Ajanlar inanılmaz kuvvetli aletler. Onları “30 saniyede özellik üreten sihirli sopalar” olarak görmek başarısızlık. Onları “bir senior mühendisin uzantısı olan stajyer” olarak görmek başarı. Hangi tarafı seçtiğin, ortaya çıkan yazılımın kalitesini belirliyor.

İki yılın sonunda hâlâ aynı disipline uyuyorum çünkü işliyor.

pgBackRest ile PostgreSQL Backup Stratejisi

info@muhammetsafak.com.tr (Muhammet Şafak) — Fri, 08 May 2026 00:00:00 GMT

pg_dump ile uğraşmayı bıraktığım gün, sistem yazılım mühendisi olarak ciddiyetimin arttığını düşünüyorum. pg_dump bir araştırma aracı — production yedek aracı değil.

Üretim yedeği üç şeyi sağlamalı:

Point-in-time recovery (PITR). “Dün gece 02:13’te silindi” diyebilmek.
Bütünlük doğrulaması. Yedek dosyasının açıldığında çalıştığını test etmek.
Saklamayı politikayla yönetmek. 6 saatlik/günlük/haftalık rotasyon.

pg_dump üç maddeyi de karşılamıyor.

pgBackRest kurulumu

Ben hem yerel hem de S3 yedeği almayı tercih ve tavsiye ediyorum. Yerel yedekler hızlı, S3 yedekleri ise yangına dayanıklı.

Off-site kopya

Repository tek bir diskte duruyorsa bir VPS yangını her şeyi siler. pgBackRest S3 veya S3-uyumlu (R2, MinIO) bucket’a yazabiliyor:

Tercih: bucket’ı versiyon-kilitli ve delete’i yasaklayan bir policy ile koruyun. Ransomware senaryosunda kritik.

Maliyetleri uzun vadeli kontrol altında tutmak için bucket yaşam döngüsünü ayarlayın:

30 Gün → Glacier Anında Alma → 120 Gün → Sil

/etc/pgbackrest.conf:

[global]

###################################
# Local Repository
###################################
repo1-path=/var/lib/pgbackrest
repo1-retention-full=4
repo1-retention-diff=14
repo1-bundle=y
repo1-block=y
repo1-cipher-pass=...
repo1-cipher-type=aes-256-cbc

###################################
# AWS S3 Repository
###################################
repo2-type=s3
repo2-path=/main
repo2-s3-bucket=...
repo2-s3-endpoint=s3.{region_name}.amazonaws.com
repo2-s3-region={region_name}
repo2-s3-key=...
repo2-s3-key-secret=...
repo2-bundle=y
repo2-block=y
repo2-cipher-type=aes-256-cbc
repo2-cipher-pass=...

###################################
compress-type=zst
compress-level=6
process-max=4
start-fast=y
log-level-console=info
log-level-file=detail
log-path=/var/log/pgbackrest

[main]
pg1-path=/var/lib/postgresql/16/main
pg1-port=5432

Yetkileri sıkılaştırın:

sudo chown postgres:postgres /etc/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest.conf

Stanza oluşturun:

sudo -u postgres pgbackrest --stanza=main stanza-create

postgresql.conf tarafında ise WAL archiving’i pgBackRest’e yönlendiriyoruz:

archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
archive_timeout = 60
wal_level = replica

archive_timeout = 60 — son 60 saniyenin işlemleri kaybedilebilir; çoğu uygulama için yeterli, finansal işlemler için değil.

Backup planı

Cron tarafında:

# Yerel repository (repo1)
0 2 * * 0          pgbackrest --stanza=main --repo=1 --type=full backup
0 2 * * 1-6        pgbackrest --stanza=main --repo=1 --type=diff backup
0 0,6,12,18 * * *  pgbackrest --stanza=main --repo=1 --type=incr backup

# S3 repository (repo2)
0 4 * * 0          pgbackrest --stanza=main --repo=2 --type=full backup
0 4 * * 1-6        pgbackrest --stanza=main --repo=2 --type=diff backup
0 3,9,15,21 * * *  pgbackrest --stanza=main --repo=2 --type=incr backup

İki repo yapılandırıldığında --repo şart: verilmezse pgBackRest yalnızca en yüksek öncelikli repoya (repo1) yedek alır, S3’te arşivlenen WAL’dan başka bir şey durmaz — tek başına restore edilemeyen bir kopya.

Her repoda haftalık full, günlük diff, 6 saatlik incremental. Storage tüketimi şaşırtıcı derecede düşük — konfigürasyondaki repoN-bundle/repoN-block satırları block incremental yedeği açıyor, böylece pgBackRest dosyanın tamamını değil yalnızca değişen bloklarını kopyalıyor; ikisi de varsayılanda kapalı.

Bütünlük: yedek varsa restore edilebilir mi?

Yedeği almak yeterli değil. Haftada bir restore tatbikatı:

pgbackrest --stanza=main --delta restore --pg1-path=/tmp/pg_restore_test

Sonra o instance’ı geçici bir port üzerinde başlatıp birkaç sanity query çalıştırıyorum. Bu adım atlanırsa yedek sahte güven olur.

PITR provası

Belirli bir zamana geri dönmek:

pgbackrest --stanza=main \
  --type=time \
  --target='2026-05-07 02:13:00+03' \
  restore

Bu komutun gerçek bir incident’te ilk kez çalıştırılması felakettir. Provayı önceden yapın — adımlar runbook’a yazılsın.

Saklama

Repository’deki kullanılmayan yedeklerin temizliği expire komutuyla:

pgbackrest --stanza=main expire

repo1-retention-full=4 ile son 4 full yedek tutuluyor; daha eskileri (ve onlara bağlı diff/incr’ler) otomatik temizleniyor.

Sonuç

Schema kopyalamak veya küçük bir tabloyu taşımak için pg_dump hâlâ doğru araç. Ama PITR isteyen herhangi bir sistemde yedek yazılımı pgBackRest (veya barman, ya da veritabanı sağlayıcının kendi aracı) olmalı. Backup’ın test edilmediği anda “backup’ım var” demek yalan söylemenin sofistike bir yoludur.

Laravel Queue Production'da Neden Yavaşlar?

info@muhammetsafak.com.tr (Muhammet Şafak) — Sun, 03 May 2026 00:00:00 GMT

“Bu queue yerelde çalışıyordu” cümlesi senelerdir aynı tonla söyleniyor. Production’da çalışıyor — sadece beklediğiniz hızda değil. Gerçek nedenler genelde Laravel’in dışında.

1. Queue Storage için yeterli connection pool yok

Queue Storage olarak Redis kullandığınızı varsayalım.

Default phpredis ya da predis bağlantıyı job başına değil worker süreci başına kuruyor — queue:work uzun ömürlü tek bir süreçtir ve Laravel’in RedisManager’ı çözümlediği bağlantıyı önbelleğe alır. Her job için yeni süreç doğan kurulumlarda (queue:listen, PHP-FPM istekleri) bağlantı gerçekten job başına açılır: her birinde bir TCP handshake’lik gecikme + arada bir ECONNRESET.

Çözüm: config/database.php içinde persistent => true (phpredis için) — Laravel aynı seçeneği RedisCluster’a da geçirir, yani cluster kurulumu da kapsanır. Worker başlattığınızda bağlantıyı açık bırakın:

'redis' => [
    'options' => [
        'cluster' => env('REDIS_CLUSTER', 'redis'),
        'prefix' => env('REDIS_PREFIX', ''),
        'persistent' => true,
    ],
],

Not: RabbitMQ tarafında optimizasyonun ana noktası persistent socket flag’i değil, connection lifecycle yönetimidir. Her job’da connection açmak yerine worker process başına uzun ömürlü AMQP connection kullanılmalı, channel reuse yapılmalı ve heartbeat/read-write timeout değerleri job sürelerine göre ayarlanmalıdır.

2. Job içinde sync I/O bekletmesi

Http::get() çağrısı 30 saniye timeout ile bekleyebiliyor. O job o worker’ı tutar. 10 worker, 10 yavaş upstream — kuyruğun gerisi durur.

İki kural:

Her HTTP/SQL çağrısının explicit timeout’u olsun. Default 30 saniye değil 5.
Beklenmesi gereken işler delay’li ayrı bir kuyrukta tutulsun (örn. webhook retry’leri için slow kuyruğu, hızlı işler default kuyruğunda).

3. Supervisor `numprocs` yanlış

Tek bir queue worker tek bir PHP process’tir. Tek bir PHP process tek bir CPU core’unu kullanır. 4 core’lu sunucuda 1 worker çalıştırmak nproc * 0.75’i atıl bırakıyor demektir.

Tipik kural: numprocs = nproc (CPU-bound) veya numprocs = 2 * nproc (I/O-bound). Her uygulamayı ölçün.

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/app/artisan queue:work redis --queue=default --sleep=1 --tries=3 --max-time=3600
autostart=true
autorestart=true
numprocs=4
user=www-data
redirect_stderr=true
stdout_logfile=/var/log/laravel-worker.log
stopwaitsecs=3600

stopwaitsecs=3600 önemli — Supervisor restart’ı sırasında uzun bir job’u yarıda kesmesin.

4. Memory leak’e karşı yeniden başlatmıyorsunuz

Long-running PHP process’ler memory’i biriktirir. --max-time=3600 veya --max-jobs=1000 ile worker’lar periyodik olarak kendilerini sonlandırmalı ve Supervisor tarafından yeniden başlatılmalı. Aksi takdirde:

Worker 8 GB RAM tüketir.
OOM killer onu öldürür.
Hangi job’u yarıda kestiği belirsiz.

5. Job batch’leri için tek bir kuyruk kullanmak

Yüksek hacimli “send notification” job’larıyla az sayıda “process payment” job’unu aynı kuyruğa atınca:

50.000 notification 30 dakika kuyruğu tıkar.
Payment job’u bekler.
Müşteri “ödemem geçmedi” diye yazar.

Prioritize: önemli işleri ayrı kuyruklara koyun ve worker --queue=payments,default,low şeklinde sıralı dinlesin.

Görmeniz gereken metrikler

Üç şey yeterli:

Kuyruk uzunluğu (Redis: kuyruk listesi için LLEN — delayed ve reserved job’lar ayrı sorted set’lerde durur, onların ZCARD’ını da ekleyin).
Job süresi p95 (kendi instrumentation’ınız — Horizon’un metrik panosu throughput, bekleme süresi ve ortalama runtime verir, yüzdelik dilim vermez).
Failed job sayısı son 5 dakikada.

Bu üçü dashboard’da olsun ve eşik geçince alarm üretsin.

Queue yavaşlığının %90’ı bu listedeki bir şeydir. Geri kalan %10 ise gerçek bottleneck’ler (database, external API) — onları bulmak için doğru ölçümünüz olmalı. Production’da “queue yavaş” hipotez değil, ölçülmüş bir şey olmalı.

Tek VPS Üzerinde Çoklu Proje Mimarisi

info@muhammetsafak.com.tr (Muhammet Şafak) — Thu, 30 Apr 2026 00:00:00 GMT

Küçük ve orta SaaS projeler için tek bir VPS, birden fazla uygulamayı barındırmak için fazlasıyla yeterli. Kubernetes, mesh, “cloud native” baskısı pek çok ekibi bu yoldan saptırıyor — ama eğer toplam yük 1 makineye sığıyorsa, dağıtım maliyeti neredeyse her zaman değmez.

Bu yazıda kullandığım örüntüyü adım adım göstereceğim.

Hedef

3–5 bağımsız Laravel uygulaması.
Her uygulama kendi domain’i, kendi süreci, kendi kullanıcısı.
PostgreSQL ve Redis paylaşılıyor: PostgreSQL’de role bazında izole, Redis’te prefix’le ayrılmış.
Deploy bir komutla, zero-downtime.
Backup ve monitoring tek yerden.
Tüm bunlar < $40/aylık bir VPS’te.

Kullanıcı ve dosya yerleşimi

Her uygulama kendi unix kullanıcısını alıyor:

billing:billing  /var/www/billing
notify:notify    /var/www/notify
blog:blog        /var/www/blog

www-data (Nginx) gruba dahil ediliyor, kod dizinine okuma erişimi için. Yazma sadece kendi uygulamasının kullanıcısında. Bu izolasyon hatalı davranan bir uygulama diğerlerine zarar veremesin diye değil; bir geliştirici hatasının diğer projeyi etkilemesini önlemek için — ki bu çok daha sık olan senaryo.

PHP-FPM pool’ları

Nginx + PHP-FPM Pool Ayrımı yazısında detaylı. Burada özet: her uygulama kendi pool.d/*.conf dosyasında pm.max_children, memory_limit ve unix kullanıcısıyla tanımlanıyor.

Veritabanı: paylaşılan PostgreSQL

Tek bir PostgreSQL cluster, her uygulama için ayrı bir database ve role:

CREATE ROLE billing_app LOGIN PASSWORD '...';
CREATE DATABASE billing OWNER billing_app;
REVOKE ALL ON DATABASE billing FROM PUBLIC;

pg_hba.conf:

host  billing  billing_app  127.0.0.1/32  scram-sha-256
host  notify   notify_app   127.0.0.1/32  scram-sha-256
host  blog     blog_app     127.0.0.1/32  scram-sha-256

Hiçbir uygulama diğerinin DB’sini göremez bile.

pgBouncer’la bağlantı havuzu

PHP-FPM bağlantıyı varsayılan olarak per-request açıp kapatıyor — kalıcı bağlantıyla (PDO::ATTR_PERSISTENT) bile bağlantı tek bir worker’a bağlı kaldığı için paylaşılan bir havuz yok. PostgreSQL bağlantı kurulumu (~10ms) kümülatifte ciddi. pgBouncer önünde pool_mode = transaction ile bunu çözüyoruz. auth_query yazısı detayı veriyor.

Redis: paylaşılan, namespace’le izole

Tek bir Redis instance. Her Laravel uygulaması farklı bir prefix:

'redis' => [
    'cache' => [
        'host' => '127.0.0.1',
        'database' => 0,
        'prefix' => 'prod:billing:cache:',
    ],
    'queue' => [
        'host' => '127.0.0.1',
        'database' => 0,
        'prefix' => 'prod:billing:queue:',
    ],
],

Prefix bir adlandırma sözleşmesi, bir sınır değil: üç uygulama da aynı instance’a, aynı database 0 üzerine, requirepass ve ACL olmadan bağlanıyor — yani biri diğerinin anahtarlarını okuyabilir. Bunun zorlanması gerekiyorsa her uygulamaya kendi Redis ACL kullanıcısını verin.

Detay namespace izolasyonu yazısında.

Queue worker’ları

Supervisor her uygulamanın queue worker’ını ayrı bir process grubu olarak yönetiyor:

/etc/supervisor/conf.d/
├── billing-worker.conf
├── notify-worker.conf
└── blog-worker.conf

Her dosyada uygulama kendi kullanıcısı ile çalışıyor:

[program:billing-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/billing/current/artisan queue:work rabbitmq --queue=default --sleep=1 --max-time=3600
user=billing
numprocs=4
autostart=true
autorestart=true
stopwaitsecs=3600

Deploy: symlink swap

Her uygulama dizininde:

/var/www/billing/
├── releases/
│   ├── 2026-05-12-1430/
│   ├── 2026-05-13-0900/
│   └── 2026-05-13-1100/    ← yeni release
├── shared/
│   ├── .env
│   ├── storage/
│   └── uploads/
└── current → releases/2026-05-13-1100

Deploy adımları:

Yeni release klasörünü oluştur, git checkout, composer install, build.
shared/ içeriklerini sembolik linkle.
Migrate (forward-compatible olmalı).
current symlink’i atomik olarak yeni klasöre çevir (ln -sfn).
PHP-FPM’e kill -USR2 ile graceful reload gönder (opcache invalidation).
Supervisor’ı sadece queue worker’ları için yeniden başlat.

Beşinci adımda bir uyarı var: USR2 FPM master’ına gidiyor ve bütün pool’ları graceful biçimde yeniden yüklüyor — tek bir pool’u yeniden başlatan bir sinyal yok. Yani bir projenin deploy’u bütün projelerin worker’larını geri döndürüyor ve ortak opcache’i boşaltıyor; yukarıdaki izolasyon çalışma zamanında geçerli, deploy yolunda değil.

Eski release’leri saklamak (örn. son 5) rollback’i bir komuta indirgiyor: symlink’i eski klasöre çevir, PHP-FPM reload.

Backup

PostgreSQL: pgBackRest, repository S3-uyumlu kovaya yazıyor.
Redis: AOF kapalı, RDB her saat. Cache-only kullanım için yeterli.
Uploads (shared/uploads): rclone ile saatlik S3 sync.
/etc: günlük tar + S3 (config’in versiyon kontrolü).

Monitoring

Self-hosted bir Prometheus + Grafana abartı olur bu ölçek için. Tercih ettiğim:

uptime-kuma — her domain’i HTTP check’le izliyor, Slack/Telegram alarmı.
node_exporter + Cloudflare metrics — sunucu sağlığı.
PHP-FPM /status endpoint — slow request sayısını izle.
logrotate — /var/log/{nginx,php-fpm,laravel}/*.log günlük.

Limitler ve büyüme sinyalleri

Bu mimari aşağıdaki sinyallerden biri görülünce kırılır:

CPU sürekli > %70. Vertical scale (daha büyük VPS) bir kez yapılır, sonra uygulama ayrıştırması.
Tek bir uygulama DB’de baskın hale gelirse. O uygulama kendi PostgreSQL’ine taşınır — replica veya managed servis.
Coğrafi gecikme şikayetleri. Bu durumda CDN’e statik asset taşıma yeterli; app server’ı taşımak ekstrem.

Niye Kubernetes değil?

Üç sebep:

Operasyon yükü. Tek başınıza bir k8s cluster’ı çalıştırmak, üzerinde uygulama yazmaktan daha fazla zaman alır.
Maliyet. Control plane’i ayrıca ücretlendiren sağlayıcılarda — EKS cluster başına saatlik $0.10, yani tek node eklenmeden ~$73/ay — 3 küçük node’lu managed k8s, eşdeğer VPS’in 3–5 katı tutuyor. Ücretsiz verenlerde fark kapanıyor: DigitalOcean’da 3 × $12/ay node ücreti VPS parasına yakın.
Karmaşıklık ödülü yok. Bu uygulamalar bağımsız ölçeklenmek zorunda değil.

Bu mimari “lazy-eval k8s” değil — başka bir paradigma. Sade, anlaşılır, operasyonel olarak küçük bir mimari. Lazım olduğunda parçalanır, ondan önce değil.

Nginx + PHP-FPM Pool Ayrımı

info@muhammetsafak.com.tr (Muhammet Şafak) — Sun, 26 Apr 2026 00:00:00 GMT

VPS üzerinde iki, üç, beş PHP uygulaması çalıştırmak — küçük SaaS dünyasında çok normal. Default kurulumda hepsi tek bir www.conf pool’unu paylaşıyor. Bu çoğu zaman çalışıyor — çalışmayana kadar.

Tek pool’un sorunu

Tek pool şu anlama geliyor:

Bir uygulama pm.max_children = 50’yi tüketirse diğerleri response üretemez.
Bir uygulamadaki memory leak diğerlerinin worker’larını da OOM’a sürükler.
Bir uygulamayı yeniden başlatmak (örn. opcache reset) hepsinin worker’larını yeniden başlatır.

Pool ayrımı ilk iki sorunu çözüyor. Üçüncüsünü çözmüyor: PHP-FPM’de pool başına reload yok — tek yeniden yükleme sinyali SIGUSR2, master altındaki tüm worker’ları yeniden yüklüyor.

Pool başına config

/etc/php/8.4/fpm/pool.d/billing.conf:

[billing]
user = billing
group = billing
listen = /run/php/billing.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500

request_terminate_timeout = 30s
catch_workers_output = yes
decorate_workers_output = no
clear_env = no

php_admin_value[memory_limit] = 256M
php_admin_value[error_log] = /var/log/php-fpm/billing-error.log

/etc/php/8.4/fpm/pool.d/notify.conf:

[notify]
user = notify
group = notify
listen = /run/php/notify.sock
; ...
pm.max_children = 8       ; daha hafif uygulama
php_admin_value[memory_limit] = 128M

İki şey kazandık:

Filesystem izolasyonu — user = billing ile billing uygulaması notify’ın dosyalarına yazamaz.
Resource izolasyonu — billing’in pm.max_children’i tükenirse notify hâlâ çalışır.

Nginx tarafında

Her vhost kendi socket’ine bağlanıyor:

server {
    server_name billing.example.com;
    root /var/www/billing/public;

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/billing.sock;
        # standart fastcgi params
    }
}

server {
    server_name notify.example.com;
    root /var/www/notify/public;

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/notify.sock;
    }
}

opcache shared mı, ayrı mı?

PHP-FPM master process’i opcache’i paylaşıyor — bu yüzden pool’lar arasında opcache otomatik izole değildir. opcache.validate_root = 1 bunu değiştirmiyor: bu direktif chroot’lu ortamlardaki ad çakışmalarını önlemek için / dizininin inode’unu önbellek anahtarına katıyor, yani ayırt ettiği şey chroot kökleri, metindeki Nginx root path’leri değil — ve buradaki pool’larda chroot yok. Pratikte: aynı master, ayrı pool’lar yeterli.

İzleme

/status endpoint’ini pool’a açın:

pm.status_path = /status

Sonra Nginx tarafında bunu sadece localhost’a açın:

location ~ ^/status$ {
    access_log off;
    allow 127.0.0.1;
    deny all;
    fastcgi_pass unix:/run/php/billing.sock;
    # ...
}

curl localhost/status ile aktif worker, kuyruk uzunluğu, slow request sayısı gibi metrikleri alıp Prometheus exporter veya basit bir cron’la izleyebilirsiniz.

Ne zaman tek pool yeterli?

Aynı kod tabanının iki kopyasını çalıştırıyorsanız (örn. app.example.com ve staging.example.com) ayrı pool gereksiz. Farklı domain’ler ama aynı süreç sınıfı. Ayrım, uygulamaları operasyonel olarak bağımsız kılmak istediğinizde değerli.

Laravel Production Stack

info@muhammetsafak.com.tr (Muhammet Şafak) — Wed, 22 Apr 2026 00:00:00 GMT

Laravel’i geliştirmek bir saat, production’a ciddi şekilde koymak bir hafta sürer. Bu yazıda kullandığım stack’i ve her bileşenin niye orada olduğunu anlatıyorum. “Her şey gerekli” demiyorum — gerekli olduğunu anlayana kadar minimum tutmayı savunan biriyim — ama her bileşenin kazandırdığı somut.

Neden sunucuları Cloudflare arkasına koyuyorum?

DDoS koruması, WAF, rate limiting gibi özellikler out-of-the-box.
Gerçek client IP’sini X-Forwarded-For ve CF-Connecting-IP header’larıyla geçiriyor; aşağıdaki real_ip yönergeleriyle uygulamanın gördüğü IP bu oluyor.
SSL termination’ı Cloudflare’da yapıp backend’e http ile konuşmak mümkün.
CDN özellikleriyle static asset’leri Cloudflare cache’inden servis etmek kolay.
Ücretsiz 15 yıllık SSL sertifikası sağlıyor, yönetimi basitleştiriyor.

Nginx — neden Apache değil?

İkisi de çalışıyor. Nginx tercih ediyorum çünkü:

Asenkron event loop modeli düşük gecikmede daha tutarlı.
TLS termination’ı, static asset serving’i, fastcgi’yi tek configde tertemiz hallediyor.
try_files $uri $uri/ /index.php?$query_string deyimi Laravel için kanonik.

Tipik server block:

# -----------------------------
# HTTP → HTTPS redirect
# -----------------------------
server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

# -----------------------------
# HTTPS
# -----------------------------
server {
    listen 443 ssl http2;
    server_name app.example.com;
    root /var/www/app/current/public;
    index index.php;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    client_max_body_size 25M;

    access_log /var/log/nginx/app.example.com.access.log;
    error_log  /var/log/nginx/app.example.com.error.log warn;

    # Cloudflare arkasında gerçek client IP, her aralık için bir satır: https://www.cloudflare.com/ips/
    set_real_ip_from 173.245.48.0/20;
    set_real_ip_from 103.21.244.0/22;
    # ... kalan Cloudflare aralıkları
    real_ip_header CF-Connecting-IP;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.4-fpm-app-example.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_buffering on;
        fastcgi_read_timeout 60s;
    }

    location ~* \.(css|js|png|jpg|jpeg|gif|svg|woff|woff2)$ {
        expires 1y;
        add_header Cache-Control "public, max-age=31536000, immutable";
        # bu seviye kendi add_header'ını tanımlayınca üsttekiler miras alınmıyor
        add_header X-Frame-Options "SAMEORIGIN";
        add_header X-Content-Type-Options "nosniff";
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        access_log off;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

set_real_ip_from listesi bütün Cloudflare aralıklarını kapsamalı; kapsamazsa Nginx client’ın değil Cloudflare’in IP’sini loglamayı sürdürür. Nokta dosyası bloğunun tek olması da bilinçli: Nginx eşleşen ilk regex location’da durur, dolayısıyla bunun ardına konan istisnasız bir location ~ /\. bloğu /.well-known/ isteklerini de yutar ve ACME doğrulamasını kırar.

PHP-FPM — pool yapılandırması

Detayını ayrı yazıda ele aldım. Production’a özel opcache ayarları:

opcache.enable=1
opcache.memory_consumption=192
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0   ; deploy'da reset gerek
opcache.preload=/var/www/app/current/preload.php
opcache.preload_user=app        ; php-fpm master root başlar, bu olmadan preload reddedilir

validate_timestamps=0 ile dosya değişikliklerini PHP otomatik algılamıyor — deploy sonrası kill -USR2 ile FPM reload zorunlu. Karşılığında saniyede yüzlerce request farkı.

PostgreSQL — neden MySQL değil?

İkisi de çalışıyor. PostgreSQL’i tercih etme sebebim:

JSON/JSONB desteği MySQL’inkinden olgun (GIN index, query operators).
CTE’ler, window function’lar, materialized view’lar native.
Logical replication ve PITR tooling’i daha temiz.
Transactional DDL — migration ortasında crash olsa veritabanı temiz kalır.

Karşılığında — kurulum biraz daha disiplin ister. Tipik postgresql.conf hassasiyetleri:

shared_buffers = 4GB                # toplam RAM'in ~%25'i
effective_cache_size = 12GB          # RAM'in ~%75'i
work_mem = 16MB
maintenance_work_mem = 256MB
wal_buffers = 16MB
max_connections = 500
checkpoint_timeout = 15min
checkpoint_completion_target = 0.9
random_page_cost = 1.1              # SSD için
effective_io_concurrency = 200

Yedekler pg_dump ile değil pgBackRest ile alınıyor: full + incremental, üstüne WAL arşivinden PITR.

pgBouncer — bağlantı havuzu

PHP per-request bağlantı açar, kapatır. PostgreSQL’de bağlantı başlatmak maliyetli (fork edilen process). Önüne pgBouncer koyup transaction mode ile bunu absorb ediyoruz. auth_query notu.

Redis — üç şapka

Aynı Redis instance üç rol oynuyor:

Cache — Cache::remember(...).
Session — SESSION_DRIVER=redis.
Lock — Cache::lock(...) ile distributed mutex.

Hepsi tek Redis’te güvenle çalışır — yeter ki:

Maxmemory policy: volatile-lru (yalnızca TTL’i olan key’leri LRU ile sil).
appendonly no (cache, session ve lock için RDB yeterli).
save 900 1 300 10 60 10000 (RDB snapshot kuralları).

RabbitMQ (opsiyonel)

Laravel’in queue driver’ı olarak rabbitmq kullanıyorum — Database ya da Redis yerine. Neden?

Queue — QUEUE_CONNECTION=rabbitmq.

Redis queue driver’ı basit ama RabbitMQ’nun özellikleriyle karşılaştırıldığında eksik kalıyor:

Persistence — RabbitMQ kalıcı mesajları diske yazar; Redis kuyruğu bellekten servis eder, diske yalnızca RDB snapshot’ları ya da AOF ile iner.
Acknowledgements — RabbitMQ’da mesaj, consumer ack verdikten sonra siliniyor; Laravel’in Redis driver’ı da biten job’ı reserved kümesinden kendi siliyor. Fark temizlikte değil yeniden teslimde: Redis retry_after zaman aşımına, RabbitMQ consumer’ın bağlantısına bakıyor.
Routing — RabbitMQ’da mesajın hangi queue’ya düşeceğine exchange’ler karar veriyor; Redis’te onQueue() ile istediğiniz kadar adlandırılmış queue açabilirsiniz ama yönlendirme kararı uygulamada kalıyor.
Monitoring — RabbitMQ yönetim paneli queue’ları, mesajları, consumer’ları broker düzeyinde gösteriyor; Redis tarafında aynı görünürlüğü Horizon veriyor, o da uygulamanın dispatch ettiğiyle sınırlı.

Supervisor + Horizon

Queue worker’ları Supervisor altında çalışıyor. Horizon Laravel’in queue dashboard’u — worker’ları ona orchestrate ettirebilmek için Supervisor horizon process’ini çalıştırıyor:

[program:horizon]
process_name=%(program_name)s
command=php /var/www/app/current/artisan horizon
user=app
autostart=true
autorestart=true
redirect_stderr=true
stdout_logfile=/var/log/horizon.log
stopwaitsecs=3600

Horizon kutudan çıktığı hâliyle yalnızca redis queue bağlantısını sürüyor; yukarıdaki rabbitmq bağlantısında vladimir-yuldashev/laravel-queue-rabbitmq paketinin Horizon modu gerekiyor — RABBITMQ_WORKER=horizon, bağlantı böylece Horizon’un okuduğu event’leri yayıyor. Horizon kendi içinde worker process’lerini fork ediyor — siz config/horizon.php ile her queue’nun worker sayısını ve memory limit’ini ayarlıyorsunuz.

Scheduler

Tek bir cron yetiyor:

* * * * *  app  cd /var/www/app/current && php artisan schedule:run >> /dev/null 2>&1

Laravel kendi scheduler’ını içeride yönetiyor. withoutOverlapping() ve onOneServer() modifier’larına dikkat — çoklu sunucuda race condition önler.

Logging

JSON formatında structured log:

// config/logging.php
'channels' => [
    'production' => [
        'driver' => 'stack',
        'channels' => ['daily', 'stderr'],
    ],
    'daily' => [
        'driver' => 'daily',
        'path' => storage_path('logs/laravel.log'),
        'level' => env('LOG_LEVEL', 'info'),
        'days' => 14,
        'formatter' => Monolog\Formatter\JsonFormatter::class,
    ],
],

/etc/logrotate.d/laravel-app:

/var/www/app/shared/storage/logs/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 app app
    sharedscripts
}

.env management

.env her zaman shared/ dizininde, deploy’lara symlink. Hiçbir zaman repo’da değil. Secrets için bunu basitliğin gücüyle yapıyorum — vault gerekirse ekleriz, başta gerek yok.

Deploy

Symlink swap modeli. Detaylar çoklu proje mimarisi yazısının “Deploy” bölümünde.

Hangi parçası kaldırılırsa ne kaybedersiniz?

Bileşen	Çıkarınca olan
pgBouncer	Connection storm’larında PostgreSQL bağlantısı tükenir, request’ler 500 atar
Supervisor	Worker’lar crash sonrası geri gelmez, alarm kurmak zorundasınız
Horizon	Görünürlük çöker, “queue neden yavaş” sorusunu kör cevaplarsınız
opcache	Her request PHP dosyasını disk’ten okur ve parse eder, ~5x yavaşlama
pgBackRest	`pg_dump` kalır — PITR kaybedersiniz, gerçek bir incident’ta hata payınız tek bir günlük yedek
Redis lock	Race condition’lara açıksınız, distributed-safe mutex’iniz kalmaz

Boring stack’in gücü tam burada: her parça nicel olarak değerli ve değişimi kolay. “Bütün cluster çöktü” senaryosu yerine “Redis maxmemory ayarını kaçırmışım” senaryosu yaşarsınız — ki bunu da düzeltmek beş dakika.

pgBouncer auth_query ile Çoklu DB Kullanıcısı

info@muhammetsafak.com.tr (Muhammet Şafak) — Sun, 19 Apr 2026 00:00:00 GMT

pgBouncer connection pooler olarak harika; ancak default yapılandırması bir düşmanlığı kabul ediyor: kullanıcı listenizi manuel olarak userlist.txt’ye yazmak zorundasınız. Her yeni DB kullanıcısı eklediğinizde dosyayı güncellemek, hash’i hesaplamak, pgBouncer’ı reload etmek. Operasyonel bir baş ağrısı.

auth_query bunu çözüyor: pgBouncer doğrulama için PostgreSQL’in kendisine sorgu atıyor.

auth_user kurulumu

PostgreSQL tarafında düşük yetkili bir kullanıcı ve pg_shadow’u okuyan bir fonksiyon oluşturuyoruz:

CREATE ROLE pgbouncer LOGIN PASSWORD 's3cr€t_p@ssw0rd';

CREATE SCHEMA pgbouncer;
GRANT USAGE ON SCHEMA pgbouncer TO pgbouncer;

CREATE OR REPLACE FUNCTION pgbouncer.user_lookup(in i_username text,
                                                 out uname text,
                                                 out phash text)
RETURNS record AS $$
BEGIN
    SELECT usename, passwd FROM pg_catalog.pg_shadow
    WHERE usename = i_username INTO uname, phash;
    RETURN;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

REVOKE ALL ON FUNCTION pgbouncer.user_lookup(text) FROM PUBLIC;
GRANT EXECUTE ON FUNCTION pgbouncer.user_lookup(text) TO pgbouncer;

SECURITY DEFINER önemli — fonksiyon pg_shadow’a erişim için tanımlayan kullanıcının yetkilerini kullanıyor. Aksi takdirde pgbouncer rolü pg_shadow’u okuyamaz.

auth_query hedef veritabanının içinde çalışır; bu yüzden fonksiyonu pgBouncer’ın hizmet vereceği her veritabanına kurmanız gerekir.

pgBouncer config

pgbouncer.ini:

[databases]
* = host=127.0.0.1 port=5432

[pgbouncer]
listen_addr = 127.0.0.1
listen_port = 6432

auth_type = scram-sha-256
auth_user = pgbouncer
auth_query = SELECT uname, phash FROM pgbouncer.user_lookup($1)

pool_mode = transaction
max_client_conn = 1000
default_pool_size = 25

Artık userlist.txt yok. PostgreSQL’de yeni bir rol oluştursanız, pgBouncer restart’ı gerektirmeden doğrulama çalışıyor.

md5 vs scram-sha-256

PostgreSQL 14+ default olarak scram-sha-256 kullanıyor. pgBouncer bunu 1.11’den beri destekliyor; auth_query ile SCRAM pass-through ise 1.14 ile geldi. Eski cluster’larda md5’e düşmek zorunda kalıyorsanız:

auth_type = md5

Ama yeni kurulum yapıyorsanız scram-sha-256 kullanın — md5 artık zayıf.

Pool mode tercihi

Üç mod var, çoğu Laravel/Django uygulaması için tercih:

session — bağlantı baştan sona aynı. Prepared statement’lar çalışır, ama pool faydası zayıf.
transaction — her transaction sonunda bağlantı serbest. En yaygın tercih. Protokol düzeyi prepared statement’lar 1.21+ gerektiriyor; 1.24’ten beri varsayılan olarak açık (max_prepared_statements = 200).
statement — her query sonunda. Çoğu ORM ile sorunlu.

Pratik: transaction’la başlayın, sorun yaşarsanız session’a geçin.

Yaygın hata: read-only role’ün password’ü yok

auth_query pg_shadow.passwd’i okuyor. Eğer kullanıcı SSO ile geliyorsa veya peer authentication kullanıyorsa, passwd alanı NULL’dur — pgBouncer login’i reddeder. Bu durumda pg_hba.conf üzerinden trust veya peer kurmak gerekir, ama production’da bunu istemezsiniz.

İzleme

pgBouncer kendi admin DB’sini sağlıyor:

psql -p 6432 pgbouncer -U pgbouncer
> SHOW POOLS;
> SHOW STATS;
> SHOW CLIENTS;

cl_waiting > 0 görüyorsanız default_pool_size’ı arttırmak gerekiyor olabilir. sv_idle çok yüksekse tam tersi — pool overprovision’da.

sade.dev

İndeks Yönetimi: Eksik Yavaşlatır, Fazlası Yazmayı Öldürür

İndeks ücretsiz hız değildir

Eksik indeks: tahmin değil, ölçüm

Fazla indeks: kullanılmayanı bul

Doğru indeksi seçmek

Duplikat ve örtüşen indeksler

Denge sorgu planıyla kurulur

Canlıda Sıfır Kesintiyle Şema Değiştirmek

Lock’u kim alır

Tehlikeli olan tek adımdır

Güvenli reçeteler

Kod ve şema birlikte uyumlu olmalı

Read/Write Splitting: Okuma ve Yazma Yükünü Ayırmak

Çoğu yük okuma ağırlıklıdır

Önce: bu gerçekten bir kapasite sorunu mu?

Replica okumayı ölçekler, yazmayı değil

Laravel’de kurulum

Replication lag: asıl fatura

Sorgu sınıflandırma disiplini

Ne zaman gerçekten gerekir

Redis Koymadan Önce: Doğru Cache Stratejisi

Cache bir tutarlılık ödünüdür

Önce sorulacak sorular

Invalidation neden zor

İki strateji

Cache yazmayı azaltmaz

Pratik kalıplar

NoSQL Tuzağı: "Şeması Yok" Diye Başlamak

”Şemasız” bir yanılgı

Şema nereye taşınır

Çarpılan krizler

NoSQL’in gerçekten doğru olduğu yerler

Esneklik istiyorsanız PostgreSQL zaten veriyor

PostgreSQL Her Şeye Yeter mi?

PostgreSQL’in az bilinen genişliği

Tek sistemin sessiz getirisi

Sınır nerede başlar

Karar: önce PostgreSQL, sonra ölçüm

Bir Sistemin "Gereğinden Karmaşık" Olduğunu Gösteren Sinyaller

Karmaşıklık nasıl birikir

Somut sinyaller

Sadeleştirmeye nereden başlanır

Karmaşıklık her zaman kötü değil

Dış Servis Entegrasyonlarında Circuit Breaker

Zincirleme çöküş nasıl olur

İlk savunma: timeout

İkinci savunma: retry — ama dikkatli

Üçüncü savunma: circuit breaker

Fallback: devre açıkken ne yapılır

Ne zaman bu kadarına gerek yok?

Serverless'a Geçiş Kararı: Cold-Start ve Vendor Lock-in

Serverless ne satın alır

Cold-start’ın gerçek maliyeti

Vendor lock-in

Hangi iş yükünde kazandırır

Hangi iş yükünde kaybettirir

Laravel ve serverless

Karışık kullanın

BFF Pattern: Mobil ve Web İçin Ayrı API Katmanı

BFF nedir

Tek API’yi herkese uydurmanın gizli maliyeti

BFF ne zaman gerekli

BFF ne zaman gereksiz

BFF mikroservis değildir

Hafif başlayın

Senkron mu, Asenkron mu? HTTP ile Kuyruk Arasındaki Sınır

Karar çizgisi: kullanıcı sonucu bekliyor mu?

Senkron kalması gerekenler

Kuyruğa gitmesi gerekenler

Çizgiyi yanıt süresi keskinleştirir

Hata toleransı: asıl ayrım

202 ve durum sorgusu kalıbı

Sınır nerede kalkar?

Transactional Outbox: Dual-Write, At-Least-Once ve İdempotent Tüketim

Dual-write: bir transaction’ı iki sisteme yayamazsınız

Outbox: önce tek sisteme yaz, sonra ayrı bir süreç yayımlasın

Relay’i nasıl beslersiniz: polling mi, CDC mi?

Çoklu relay: SKIP LOCKED ile çakışmasız dağıtım

Ordering: neyi garanti edebilirsiniz, neyi edemezsiniz

Çoklu relay: `SKIP LOCKED` ile çakışmasız dağıtım

`processed_messages` sonsuza kadar büyüyemez