Solution Architecture
HLD/LLD, Arayüzler ve İşletilebilirlik
HLD ve LLD'yi doğru soruya göre katmanla
Ön koşul: Arven bağlam ve kalite senaryolarını, üç mimari seçeneği, ADR-001 durumunu ve sizing/BoM koşullarını okuyabilmelisin. Bu dersin sonunda HLD ve LLD kapsamını ayıracak; bileşen, veri akışı, zaman dizisi ve deployment görünümünü aynı karar sürümüne bağlayacak; arayüz sözleşmesi, gözlemleme, runbook ve migration yükümlülüklerini açık bir devir paketine çevireceksin. Yaklaşık 27 dakika anlatı, 27 dakika tasarım egzersizi ve 14 dakika kontrol önerilir. High-Level Design, iş ve platform paydaşının mimari yapıyı, sınırları ve başlıca kararları anlamasını sağlar. Low-Level Design, uygulama/operasyon ekibinin arayüz, adresleme, kural, sürüm, izleme ve dağıtım ayrıntısını doğrulayabileceği düzeye iner. HLD ürün logosu kolajı, LLD de rastgele parametre listesi değildir. İkisinin ortak kaynağı aynı iş sonucu, kalite senaryosu, ADR ve POC bulgusudur.
| Görünüm | Temel soru | Kanıt bağı |
|---|---|---|
| Bağlam/HLD | Kim, hangi iş sonucuna ve dış sisteme bağlı? | İş SLO'su ve scope |
| Bileşen/HLD | Hangi işlev ve sorumluluk nerede? | ADR ve seçenek |
| Sequence/data flow/LLD | Sipariş, hata, tekrar ve veri nasıl ilerler? | Interface contract ve negatif test |
| Deployment/LLD | Hangi node, ağ, güç ve failure domain? | Sizing, BoM ve failover POC |
ÖRNEK
Kuyruk kararı iki görünümü de değiştirir
Öğretim amaçlı Arven ADR'si kuyruklu kabul pilotunu Proposed olarak seçmiş olsun. HLD bileşen görünümünde portal ile ERP arasına kabul/kuyruk işlevi ve onu yöneten ekip eklenir. LLD sequence görünümü 'alındı' ile 'ERP kabul etti' olaylarını ayırır; başarısız retry ve tekrar siparişin nasıl işlendiğini yazar. Deployment görünümü kuyruğun hangi failure domain'de çalıştığını ve tek düğüm kaybında nerede devam ettiğini gösterir. BoM'da yeni port, lisans veya storage gerekiyorsa aynı karar kimliğiyle bağlanır. Gerçek Arven tasarımının böyle olduğu ileri sürülmüyor.
MÜŞTERİYE SOR
İş, uygulama, güvenlik ve operasyon ekiplerinden hangisi hangi diyagramda hangi kararı veya riski görmek zorunda?
Görünümü okuyucu ve karar amacıyla eşleştirir; gereksiz karmaşayı önler.
ŞİMDİ SEN DENE
Dört görünümün kartını yaz
Arven için bağlam, bileşen, sequence/data flow ve deployment görünümünün başlığını, okuyucusunu, üç zorunlu öğesini ve bağlı gereksinim/ADR/POC kimliğini yaz. Her birine belirsiz bir ok veya düğüm için owner/TBD ekle. HLD ile LLD'nin farklı ayrıntı seviyesini koru.
BİLGİNİ KONTROL ET
Sipariş retry sırası ve ERP hata yanıtı hangi görünümde en açık anlatılır?
Arayüz ve veri sözleşmesini hata yoluyla birlikte tanımla
Arayüz çizgisi, gerçek bir sözleşmenin yer tutucusudur. Arven portal–ERP sipariş akışında yön ve tetikleyici, isteğin kimliği, veri sınıflandırması ve sahibi, şema/sürüm, transport, authentication/authorization, timeout, rate limit, başarı ve hata kodları, retry/backoff, ordering, idempotency, dead-letter veya manuel uzlaştırma, izleme ve support owner'ı yazılmalıdır. Hepsi aynı belgede sonsuz ayrıntıya dönüşmemeli; HLD bu sözleşmenin varlığını ve karar etkisini gösterir, LLD uygulanabilir parametre ve test senaryosunu taşır. 'ERP siparişi alır' ifadesi kabul zamanı, reddetme ve tekrar yolunu söylemez. İki sistem saat farkı veya ağ kesintisinde nasıl uzlaşır? Veri şemasının değişmesi eski istemciyi kırar mı? Bunlar yalnız geliştiricinin sonradan seçeceği mikro ayrıntı değildir; veri doğruluğu ve müşteri onayı mimari niteliğidir.
| Sözleşme alanı | Karar | Doğrulama |
|---|---|---|
| İşlem kimliği/durum | Alındı ve ERP kabulü ayrı | Çift/eksik sipariş testi |
| Timeout ve retry | Sınır, backoff, son durum sorgusu | Ağ kesintisi ve tekrar testi |
| Yetki ve veri | Servis kimliği, en az ayrıcalık, veri sınıfı | Pozitif/negatif erişim testi |
| Sürüm/owner | Şema geçişi, support ve eskalasyon | Eski/yeni istemci uyumluluğu |
ÖRNEK
Timeout, reddedildi anlamına gelmez
Öğretim amaçlı Arven akışında portal ERP'ye sipariş gönderir ve ağ timeout alır. ERP isteği işlemiş olabilir; portaldaki kör yeniden deneme ikinci üretim emri yaratabilir. LLD, tekil işlem kimliğiyle durum sorgusu, idempotent kabul veya uzlaştırma yolunu tarif eder. HLD veri bütünlüğü kararını ve sahibi gösterir. Negatif test, yanıt düşürülüp aynı siparişin tekrar gönderilmesini içerir; iş sahibi tek kayıt ve doğru müşteri durumunu kabul eder. Bu gerçek Arven hatası değildir, sınır sözleşmesi için öğretim örneğidir.
MÜŞTERİYE SOR
ERP timeout verdiğinde siparişin durumunu hangi sistemden ve hangi kimlikle doğrularsınız; çift üretim emrini kim uzlaştırır?
Teknik retry tercihinin veri bütünlüğü ve iş sahibine etkisini açar.
ŞİMDİ SEN DENE
Sipariş contract'ını tamamla
Portal–ERP akışı için istek ve yanıt durumlarını, kanonik veri sahibini, kimliği, rate limit, timeout, retry, idempotency, schema version, gözlem kimliği ve support owner'ını yaz. Normal, timeout, duplicate ve yetki reddi için dört test ekle. Bilinmeyen sınırı TBD/owner olarak işaretle.
BİLGİNİ KONTROL ET
ERP yanıtı timeout olduysa portalın ilk güvenli yorumu nedir?
Deployment, güvenlik ve işletim yolunu aynı tasarıma bağla
Deployment görünümü, uygulama bileşenlerini node, rack, site, ağ segmenti ve yönetim düzlemine yerleştirir. Arven'de portal, kuyruk, ERP gateway, veri tabanı, kimlik, backup ve izleme bileşenleri hangi failure domain'leri paylaşır? Bir düğüm veya switch kaybında hangi kopya ayakta kalır ve hangi iş SLO'su geçerlidir? HLD bu topoloji ilkesini ve tek hata sınırlarını anlatır; LLD kaynak/adres/port/zone, DNS, sertifika, deployment sırası ve destekli sürümleri doğrular. BoM'daki düğüm ve bağlantılar deployment çizimiyle birebir eşleşmelidir. İki NIC çizip yalnız bir switch'e bağlamak, yedeklilik iddiası oluşturmaz. İki site çizmek DR orkestrasyonu, kimlik bağımlılığı veya veri mutabakatı olmadan RTO/RPO kanıtı değildir. Ürün konfigürasyonu ve uyumluluk son teklif tarihinde resmî kaynakla ayrıca teyit edilir.
| Boyut | Çizim/kayıt | Kabul kanıtı |
|---|---|---|
| Yerleşim | Node/rack/site ve anti-affinity | Tek domain kaybı POC |
| Ağ/güven | Zone, port, servis kimliği ve sertifika | İzin ve negatif erişim testi |
| Gözlemleme | İşlem kimliği, p99, hata, backlog yaşı | Alarm ve triage provası |
| Değişiklik | Dağıtım sırası, rollback ve veri uzlaşması | Bakım/recovery tatbikatı |
ÖRNEK
Kuyruk çalışıyor ama sipariş kayıp
Öğretim örneğinde Arven kuyruğu teknik olarak yeşildir, mesaj sayısı sabit görünür. Ancak en yaşlı sipariş saati geçer ve ERP tarafından sürekli reddedilen kayıt dead-letter alanında birikir. Sadece düğüm health check'i izlenirse iş kesintisi kaçırılır. LLD, işlem yaşı, kabul oranı, dead-letter ve düzeltme owner'ını tanımlar; runbook, hatalı kaydı kör replay etmek yerine veri/şema nedenini ve müşteri bildirimini değerlendirir. HLD'de izleme iş sonucuna bağlanır. Bu senaryo gerçek Arven olayı değildir.
MÜŞTERİYE SOR
Sipariş kabulü yavaşlarsa bunu hangi ekip hangi dashboard/alarmla fark eder; güvenli ilk müdahale ve eskalasyon ne kadar sürede yapılır?
Mimari bileşeni işletim sorumluluğu ve ölçülebilir müdahaleye bağlar.
ŞİMDİ SEN DENE
Yerleşim ve runbook kartını çıkar
Arven portal, kuyruk, gateway, veri tabanı ve izleme bileşenlerini iki failure domain üzerinde göster. Her biri için ağ/güven sınırı, BoM bağı, kritik metrik, alarm owner'ı, bakım adımı ve rollback eşiği yaz. Bir düğüm ve bir servis kimliği kesintisini ayrı prova olarak planla.
BİLGİNİ KONTROL ET
Kuyruk health check'i yeşil ama en yaşlı sipariş gecikiyorsa mimari gözlem ne olmalıdır?
Çizim, BoM, test ve sorumluluk sürümünü tutarlı devret
Tasarım paketi bağlam, HLD, LLD, ADR, BoM, POC ve operasyon runbook'unun birbirini çelişkisiz işaretlemesidir. Arven HLD'de iki bağımsız ağ yolu vaat edilirken BoM'da tek optik veya LLD'de iki bağlantı aynı switch'e çıkıyorsa kapanış kapısı kalır. ADR kuyruklu seçeneği Proposed tutarken LLD onu kesin üretim topolojisi saymamalıdır. İş SLO'su değiştiyse POC test eşiği ve dashboard alarmı da güncellenir. Her belgeye revizyon, durum, owner, tarih, ilgili iş öğesi ve karşılıklı bağlantı ekle. 'En güncel' dosyayı e-posta eklerinden tahmin ettirme. Handover'da implementasyon ekibi uygulanacak tasarım, açık varsayım ve ret koşulunu; operasyon ekibi izleme, bakım ve incident akışını; iş sahibi kabul sınırını aynı versiyonda görür. Açık TBD kapatılmadan teknik detay üretilebilir, ama koşullu olduğunu her yerde göstermek gerekir.
ÖRNEK
Eski ADR, yeni BoM uyuşmazlığı
Öğretim örneğinde Arven POC'u sonrası üçüncü kuyruk düğümü önerilir; BoM v2 ek düğümü içerir ama deployment çizimi v1 iki düğümü gösterir. Operasyon ekibi üçüncü düğümün rack, güç, alarm ve patch kapsamını bilmez. Kapanış kontrolü, POC sonucu, ADR statüsü, HLD/LLD, BoM ve runbook'u aynı revizyona yükseltir; yeni düğümün iş kabulüne nasıl katkı verdiği ölçülür. 'BoM güncel' demek tek başına mimari teslim değildir. Gerçek Arven alımı veya topolojisi yoktur.
MÜŞTERİYE SOR
Uygulama, güvenlik, operasyon ve iş kabul ekipleri devirde hangi belgeyi imzalar; hangi açık TBD uygulamayı veya üretim geçişini durdurur?
Doküman listesini gerçek sahiplik ve karar kapısına dönüştürür.
ŞİMDİ SEN DENE
Sürüm tutarlılığı denetimi yap
Arven HLD, LLD, ADR-001, BoM ve POC için sürüm/durum/owner tablosu aç. Kuyruklu akış, iki ağ yolu, işlem kimliği, alarm ve geri dönüşün her belgede aynı kararı gösterdiğini kontrol et. Üç çelişki üret ve her biri için düzeltme sahibi, kapatma kanıtı ve karar tarihini yaz.
BU DERSTEN AL
Bu dersten taşıyacağın düşünceler
- HLD işlev, sınır ve karar ilkesini; LLD sözleşme, yerleşim ve uygulanabilir ayrıntıyı taşır.
- Arayüz oku timeout, retry, veri sahibi, yetki ve idempotency sözleşmesi olmadan tamamlanmış sayılmaz.
- Deployment, gözlemleme, runbook ve değişiklik/rollback yolu iş SLO'suyla birlikte tasarlanır.
- ADR, HLD/LLD, BoM, POC ve handover aynı revizyon ve koşullu karar statüsünü göstermelidir.