Bir mimari katayı nasıl çalışırım

Neden kata çalışıyorum

Kata bir alıştırma. Onu üretimdeki projelerimden ayrı tutuyorum ve her problem tanımı kurgusal. Hiçbir kata gerçek bir şirketin iç sistemlerini anlatmıyor.

Her problem tanımı bir sektörde zor bir problem kuruyor: anlık ödemeler, sağlık verisi paylaşımı, telekom, sigorta, perakende fiyatlama. İçinde bir arka plan, sekiz gereksinim ve teslim edilecekler listesi var. Bu sektörlerin çoğu günlük işimden uzak. Birkaçı ise ona yakın; bir veri ambarı göçü ya da bir fiyat istihbaratı platformu gibi.

Amaç kusursuz bir tasarım değil. Amaç tek bir alışkanlığı çalışmak: her bileşen sevdiğim bir araçtan değil, bir kısıttan çıkmalı.

Adımlar

1. Problem tanımı. Arka plandan ve R1’den R8’e sekiz gereksinimden başlıyorum. İçlerindeki her rakam önemli: hacimler, gecikme hedefleri, saklama süreleri, bütçeler. Kapasite hesabını sonra bu rakamlar yönlendiriyor.
2. Kısıt ve açık sorular. Tasarımı belirleyen tek kısıtı tek cümleyle yazıyorum. Ardından A1’den A8’e numaralı sekiz varsayım geliyor; her birinde gerçek bir ekibe teyit ettirmek isteyeceğim bir rakam var. Netleştiremediğim her şey açık sorular listesine giriyor.
3. 30 dakikalık canlı çizim. Tek sayfa, 12 ile 18 arası kutu. Güvenlik ve gözlemlenebilirlik en altta iki şerit olarak duruyor. Hikâye tek bakışta okunmuyorsa tasarım henüz net değil demektir.
4. Dört sayfalık set. Birinci sayfa çözüme genel bakış. İkinci sayfa veriyi durak durak izliyor ve her garantiyi açıklıyor. Üçüncü sayfa dağıtım, güvenlik ve izlemeyi kapsıyor; geçerli olduğu yerde mevzuatı madde numarasıyla anıyor. Dördüncü sayfada bir sonraki kaynağı ya da ekibi eklemek için altı adımlık bir sözleşme var. Aynı sayfa her bileşenin AWS, Azure ve Google Cloud karşılığını da gösteriyor.
5. Bileşen gerekçesi ve lisans tablosu. Bir tablo her ihtiyacı bir seçimle eşliyor ve alternatiflerin neden elendiğini söylüyor. Her satır üründen değil, ihtiyaçtan başlıyor. İkinci tablo her lisansı ve ticari desteği veren şirketi listeliyor. Ayrıca bu katada farklı seçilen bir bileşeni ve nedenini açıkça yazıyorum. Böylece katalar tek bir şablona dönüşmüyor.
6. Kapasite hesabı. Altı ile sekiz satır; her satırda hesap açıkça yazılı. GenAI ajanları katasında 8.000 çalışan, bunların %25’i aktif ve her biri üç soru sorunca günde yaklaşık 6.000 soru çıkıyor. Token bütçesini, GPU havuzunu ve iki yıllık kanıt depolamasını bu rakam belirliyor.
7. Gereksinim eşlemesi. Her gereksinim, onu karşılayan tasarım parçasını şekil numarasıyla gösteriyor. Tasarımda yeri olmayan bir gereksinim ayrıntı değil, boşluktur.
8. Açık noktalar. Katayı beş ya da altı açık nokta kapatıyor; ilk üçü genel bakış sayfasında da duruyor. Ardından kısa cevaplı zor sorular geliyor. Bu sorular, diyagramlarla metnin hâlâ aynı şeyi söyleyip söylemediğini sınıyor.

Neyi ölçmüyorum

Bir katadaki rakamlar tasarım tahminidir. Hiçbir şey yük testinden geçmedi ve çalışan bir sistem yok. Bu yüzden her kata, ölçüm değil tasarım varsayımı olduğu belirtilen sonuç notlarıyla bitiyor.

Bir iddia, dayandığı mekanizmanın ötesine de geçmiyor. “Tam olarak bir kez” ya da “veri kaybı yok” ifadesini tek başına yazmıyorum. Mekanizma asenkron kopyalamaysa, metin kurtarma noktasının kopyalama gecikmesine eşit olduğunu söylüyor. O gecikme penceresinde ne olduğunu da yazıyor.

Açık kaynak ve lisans tercihleri

Önceliğim Apache 2.0 ve MIT; ardından BSD, MPL ya da PostgreSQL lisansı gibi OSI onaylı diğer lisanslar geliyor. Her bileşenin arkasında destek satan bir şirket de olmalı, çünkü kurumsal bir müşteri bunu soracaktır.

Kaynak-erişimli lisanslar eleniyor ve tablolar bunu açıkça yazıyor. Redpanda ve HashiCorp Vault, Business Source License yüzünden dışarıda kaldı; Vault’un yerini OpenBao aldı. Redis 7.x lisans değişikliğinden sonra Redis yerine Valkey kullanıyorum. Elasticsearch yerine OpenSearch, Camunda 8 yerine Flowable ya da Temporal var. Topluluk sürümü daraldığı için MinIO yerine Ceph seçtim. TimescaleDB ise sıkıştırması Timescale License altında olduğu için elendi.

Bazı istisnalar kaçınılmaz ve onları adıyla yazıyorum. Problem tanımı istediğinde ticari LLM sağlayıcı API’leri bunlardan biri. Platformun zaten parçası olduğunda Cloud Composer gibi yönetilen bir servis de öyle.

Bulut izdüşümü aynı kurala uyuyor. Yönetilen bir servis gerçek bir karşılık değilse, hücresinde “Beam ile yeniden yazım” ya da “işlem desteği yok” gibi kısa bir boşluk etiketi var.

Bir kata nasıl okunmalı

Kapak görseliyle, yani 30 dakikalık canlı çizimle başlayın. Hikâyenin tamamını tek görünümde anlatıyor. Ardından bileşen tablosunu okuyun; gerekçenin büyük kısmı “neden” sütununda. Sonra kararlar ve ödünleşimler geliyor, her birinin bedeliyle. “Yeniden ele alacaklarım” bölümü, gerçek bir ekibe ilk soracağım soruları listeliyor.

Diyagram etiketleri İngilizce. Her katanın arkasında daha uzun bir yazılı çözüm var: 14 ile 18 sayfa arası Türkçe bir PDF.

Yapay zekâ araçlarının yeri

Yazılı çözümlerin ve diyagram tanımlarının taslağında yapay zekâ araçları kullandım. Her diyagram Python kodunda küçük bir tanım. Tek bir derleme bu tanımdan hem draw.io dosyasını hem PNG görselleri üretiyor; böylece görsel ile diyagram birbirinden kopmuyor. Bileşen seçimleri, ödünleşimler ve açık sorular benim kararım.

Katalar: tüm mimari katalar.