--- title: "Neden Boring Architecture'ı Tercih Ediyorum" description: "Yeni teknoloji peşinde koşmak yerine kanıtlanmış araçları seçmenin pragmatik gerekçesi. Bu bir korkaklık değil, bir bütçe kararı." url: https://sade.dev/tr/journal/neden-boring-architecture/ lang: tr author: "Muhammet Şafak" published: 2026-05-15 updated: 2026-09-06 section: Journal tags: ["architecture","decisions","opinion"] summary: "Her ekibin sabit bir karmaşıklık bütçesi var — kabaca üç innovation token — ve boring stack, o token'ları altyapıya harcamayı reddedince geriye kalan şey. Ben onları domain karmaşıklığına, yılda bir yeni altyapı parçasına ve tek bir küçük denemeye harcıyorum. Yeni bir aracın boring sayılması için 12–18 ay production'da kalması gerekiyor; istisnayı ise yalnızca ölçülmüş bir ihtiyaç satın alıyor." --- # Neden Boring Architecture'ı Tercih Ediyorum > Her ekibin sabit bir karmaşıklık bütçesi var — kabaca üç innovation token — ve boring stack, o token'ları altyapıya harcamayı reddedince geriye kalan şey. Ben onları domain karmaşıklığına, yılda bir yeni altyapı parçasına ve tek bir küçük denemeye harcıyorum. Yeni bir aracın boring sayılması için 12–18 ay production'da kalması gerekiyor; istisnayı ise yalnızca ölçülmüş bir ihtiyaç satın alıyor. 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: 1. **Domain karmaşıklığı.** İş kuralları, dağıtık iş akışları, eventual consistency gibi şeyler bütçe yer çünkü iş gerektiriyor. 2. **Yeni bir altyapı parçası** (örn. message broker eklemek, search engine eklemek). Yılda en fazla bir kez. 3. **İ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? 1. **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. 2. **Ekipte herkes yeni araçla deneyimli.** Eğer 5 mühendis Go ile yıllardır yazıyorsa, PHP'ye zorlamak yanlış. 3. **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. ## Sık sorulanlar **Boring teknoloji ne demek?** Öngörülebilir, iyi belgelenmiş ve kırıldığında cevabı on yıl önce yazılmış bir Stack Overflow gönderisinde bulunabilen demek. Eski doğru kelime değil — olgun doğru kelime: edge case'leri keşfedilmiş, hata mesajları arandığında cevap veriyor, ekibe yeni katılan üye ilk gününde üretken olabiliyor. Bir araç bu kategoriye kurulduğu gün değil, 12–18 ay aktif production kullanımından sonra giriyor. **Küçük bir ekip inovasyon bütçesini nereye harcamalı?** Domain karmaşıklığına, yılda en fazla bir yeni altyapı parçasına ve çoğu zaman tekrar atılan küçük bir denemeye. Bütçeyi yeni bir dil, yeni bir veritabanı türü, yeni bir mesajlaşma sistemi ve yeni bir orchestration platformu olarak harcadığınızda, gerçekten değer üreten karmaşıklığa ayıracak token kalmıyor. **Yeni bir teknoloji seçmek ne zaman haklı?** Üç durumda. Özellik kanıtlanmış bir araçla gerçekten yapılamıyorsa — gerçek zamanlı collaborative editing için CRDT gibi. Ekipteki herkes yeni araçla zaten deneyimliyse. Ve performans gereksinimi varsayılmış değil ölçülmüşse: daha hızlı olur hipotezi değil, gösterilmiş bir darboğaz. ## Kaynaklar - [Choose Boring Technology](https://mcfunley.com/choose-boring-technology) — Dan McKinley - [A Brief History of PostgreSQL](https://www.postgresql.org/docs/current/history.html) — PostgreSQL - [nginx CHANGES: 0.1.0, the first public version (04 Oct 2004)](https://nginx.org/en/CHANGES) — nginx