# Backend geliştirici: API'nin arkasındaki kuyruk, veritabanı ve sunucu > API sözleşmesi, kuyruk, veritabanı ve sunucu tarafında ne yaptığım — teslim garantisi, idempotency ve ölçülmüş index kararları. - Teknolojiler: RabbitMQ, Redis, PostgreSQL, MySQL, Elasticsearch, Docker, nginx, GitHub Actions - Deneyim: 2010'den bu yana - Yazı: 26 - Proje: 3 - Güncelleme: 2026-09-02 - Kaynak: https://www.muhammetsafak.com.tr/uzmanlik/backend/ - Dil: tr-TR - Yazar: Muhammet Şafak --- ## Bu ekosistemde ben Backend geliştirme benim için bir dil değil, bir sorumluluk sınırı: kullanıcının gördüğü ekranın arkasında kalan her şey. Sözleşme, kuyruk, veritabanı ve sunucu aynı işin dört yüzü; biri hakkında verilen karar diğer üçünü de bağlıyor. Gözlemlenebilirlik, altyapının kod olarak yönetilmesi ve geri alma stratejisi gibi başlıkları mimari konular olarak [sade.dev](https://sade.dev) tarafında yazıyorum. ### Backend'de ne yapıyorum Ortak noktaları kullanıcının gördüğü ekranın arkasında kalmaları: sözleşme, kuyruk, veritabanı ve sunucu. - **API sözleşmesi** — Yanıt biçimi, hata sözleşmesi ve sürümleme kararı kod yazılmadan önce netleşiyor. Aksi hâlde istemci tarafındaki her ekip kendi varsayımını yazıyor ve o varsayım altı ay sonra sizin sorununuz oluyor. - **Asenkron teslim hattı** — Kuyruk, consumer ve outbox relay'i; senkron beklemeyi kullanıcının önünden alan yapı. Aynı disiplinin ikinci yarısı idempotency: bir isteğin yan etkisiz olarak tekrar edilebilmesi. - **Veritabanı kararları** — Index ve plan davranışı sezgiyle değil ölçümle seçiliyor; sezgi burada özellikle kötü çalışıyor. Ölçümün kendisi bu sayfada değil, yöntemi ve ortamıyla birlikte research defterinde duruyor. - **Arama ve sunucu katmanı** — İlişkiselin yetmediği sınırda Elasticsearch; ortam Docker ile, deploy hattı GitHub Actions ile, önde nginx. Kapsam uygulama seviyesinde kalıyor. ### Kuyruk teslim garantisi vermez Sık gördüğüm yanılgı, iş kuyruğa taşındığında dayanıklı hâle geldiğinin sanılması. Zincir sırayla okunur; her adım bir öncekinin açık bıraktığı yeri kapatıyor. 1. **Yazma ile publish iki ayrı sistem** — Veritabanına INSERT ile kuyruğa publish arasında atomiklik yok. Yazma başarılı olup publish ağ takılmasıyla düşerse veritabanında kayıt vardır ve event hiç yola çıkmamıştır. 2. **Mesaj aynı transaction'a yazılır** — Mesaj kuyruğa doğrudan basılmıyor; aynı transaction içinde bir outbox tablosuna satır olarak yazılıyor. Kayıt ile mesajın kaderi böylece tek bir işleme bağlanıyor. 3. **Relay satırları yayımlar** — Ayrı bir relay o satırları okuyup kuyruğa veriyor. Mesajın kaybolmadığı yer burası — ama garantinin tamamlandığı yer değil. 4. **Garantiyi idempotent tüketici tamamlar** — Outbox at-least-once verir: mesaj kaybolmaz, tekrar edebilir. İşlenen her event id'si aynı transaction içinde processed_messages tablosuna yazılınca tekrar zararsızlaşıyor. ### Veri ve sunucu tarafında kapsamım Veritabanı kararlarını sezgiyle vermiyorum; sunucu tarafında ise kapsam uygulama seviyesinde kalıyor. - **Ölçülmüş index kararları** — Index tercihleri, sorgu planları ve tablo büyüdükçe değişen davranış ölçülerek seçiliyor. Ölçüm olmadan verilen karar, bugün hızlandırdığı sorguyu yarın yavaşlatabiliyor. - **Tam metin arama katmanı** — İlişkisel deponun yetmediği yerde devreye giriyor. Kök bulma, eş anlamlı genişletme ve alakalılık sıralaması ilişkiselde de var; ayrı bir katmanı getiren şey bu işlerin varlığı değil, ölçekte ve çok dilli metinde nereye kadar taşıdığı. - **Uygulama seviyesinde sunucu** — Çalışma ortamının paketlenmesi, test ve dağıtım hattının kurulması, uygulamanın önündeki katmanın yapılandırılması. ### Değişikliği güvenli kılan sıra Arka uçta asıl zorluk yeni bir özelliği yazmak değil, çalışan bir sistemi bozmadan değiştirmek. 1. **Şemayı eski ve yeni kodun aynı anda ayakta olduğu pencereye göre planlamak** — Eski ve yeni kod bir süre birlikte çalışıyor; şema değişikliği o pencereyi hesaba katmadan yazıldığında kırılan taraf her zaman çalışan sistem oluyor. 2. **Veri taşımasını geri alınabilir adımlara bölmek** — Tek seferde yürüyen bir taşımanın geri dönüşü yok. Adımlara bölünmüş bir taşıma, yanlış giden adımda durabiliyor. 3. **Test yüzeyini üç yerde ayrı tutmak** — İş kuralının doğrudan sınandığı yer, dış sınırın taklit edildiği yer ve akışın uçtan uca yürütüldüğü yer. Değişikliğin bedeli, getirdiği rahatlıktan küçük kalmalı. ### Altyapıyı mimari konu olarak burada yazmıyorum Gözlemlenebilirlik, IaC ve rollback stratejisi gibi başlıklar bu sayfada kendi başlarına durmuyor; buradaki kapsamım uygulama seviyesinde kalıyor. Altyapıyı bir mimari konu olarak yazdığım yer sade.dev. ## Sık sorulanlar ### Backend tarafında kaç yıldır çalışıyorsun? 2010'den bu yana, 16 yıldır. PHP'ye başladıktan iki yıl sonra işin ağırlığı sözleşmeden kuyruğa kaydı ve orada kaldı; bu sitede kayıtlı 26 yazının çıktığı yer o dönem. ### Backend tarafında en sık hangi problemle geliyorlar? Çoğunlukla "kuyruğa taşıdık ama bazı işler kayboluyor" ile geliyorlar. Cevap neredeyse her seferinde aynı yerde: veritabanına yazma ile kuyruğa publish etme iki ayrı sistem ve aralarında hiçbir atomiklik garantisi yok. ### API tasarımına nereden başlıyorsun? Sözleşmeden. Yanıt biçimi, hata sözleşmesi ve sürümleme kararları kod yazılmadan önce netleşmezse, istemci tarafındaki her ekip kendi varsayımını yazıyor. Bu sitede 26 yazının önemli bir kısmı bu üç başlığın etrafında. ### Kuyruk kullanmak teslim garantisi verir mi? Hayır. Transactional outbox mesajın kaybolmamasını sağlar ama size at-least-once verir — mesaj tekrar edebilir. Garantiyi tamamlayan şey kuyruk değil, tüketicinin idempotent olmasıdır. ### Index kararlarını nasıl veriyorsun? Ölçerek. Partial index'i yalnızca "küçük ve hızlı" diye seçmek bir tuzak: generic plan devreye girdiği anda partial index kullanılamıyor. İyi haber, uçurumun çitli olması — Postgres bu geçişi kendiliğinden yapmıyor, oraya düşmek için ayarı elle zorlamak gerekiyor. Ölçümün tamamı research defterinde duruyor. ### Sunucu tarafını da sen mi kuruyorsun? Evet, uygulama seviyesinde. Docker'la ortamı, GitHub Actions'la deploy hattını ve nginx'i kendim kuruyorum; altyapının kendisini bir mimari konu olarak yazdığım yer sade.dev. ### Kaç projede bu yığını kullandın? Bu sitede kayıtlı projelerin 3 tanesi doğrudan bu kuyruk/veritabanı yığınının üstünde duruyor.