WhiteYaka
Kütüphaneyi açKütüphane
WY · BÖLÜM 07 · FÖY 125
YAZ-125 · Yazılım & Teknik · ~2-3 dk

Bos sayfadan RFC iskeleti: baglam, secenekler, karar

Bos sayfa yerine 6 baslikli, en az iki secenegi ayni olcutlerle karsilastiran bir tasarim dokumani taslagi.

Kanca

Kafanda yeni bir teknik tasarim fikri var ama bos dokumana ilk cumleyi bir turlu yazamiyorsun. Sonunda fikri Slack'e birkac dagilmis mesajla atiyorsun; tartisma yayiliyor, karar kayitli hicbir yerde durmuyor.

Hamle — Claude / ChatGPT (ikisi de calisir)
Prompt — kopyala & yapıştır
Sen deneyimli bir yazilim mimarisin. Sana bir teknik tasarim fikrinin ham notlarini verecegim. Gorevin, bu notlardan tartismaya hazir bir tasarim dokumani (RFC) iskeleti cikarmak.

Kurallar:
- Sadece verdigim bilgiyi kullan. Eksik olan yeri uydurma; o basligin altina "EKSIK: ..." yazip hangi bilginin gerektigini belirt.
- Tahmin yurutme. Bir varsayim ekliyorsan basina "VARSAYIM:" yaz.
- Tek cozum dayatma; en az iki secenek uret ve her birini ayni olcutlerle karsilastir.
- Kisa ve net yaz, madde isareti kullan.

Su basliklari doldur:
1. Baglam ve problem: bugun ne aksiyor, bu tasarim neyi cozecek.
2. Hedefler ve kapsam disi: neler dahil, acikca neler dahil degil.
3. Secenekler: en az 2 secenek. Her birinde yaklasim, arti, eksi, tahmini maliyet/karmasiklik.
4. Karsilastirma: secenekleri performans, bakim yuku, risk ve gecis kolayligi olcutlerinde tablo halinde karsilastir.
5. Onerilen karar ve gerekce: hangi secenek, neden.
6. Riskler ve acik sorular: karar oncesi netlesmesi gereken sorular.

Ham notlarim:
[buraya fikrini, kisitlari ve mevcut sistemi yapistir]
Çıktı

Bos sayfa yerine 6 baslikli, en az iki secenegi ayni olcutlerle karsilastiran bir tasarim dokumani taslagi. Ekibe gonderilmeye hazir; sen sadece "EKSIK" ve "VARSAYIM" satirlarini gezip duzeltirsin.

Kariyer çentiği

Fikri Slack mesaji yerine yazili bir tasarim dokumani olarak acinca, karar senin adinla kayitli bir yerde durur ve tartismayi dogru yerde sen baslatirsin.

Sınır

Iskelet senin notlarindan daha iyi olamaz; secenekleri AI siralar ama son karari ve dengeleri sen dogrularsin, ayrica sirket-ici mimari detayi yapistiracaksan gizlilik sinirlarini gozet.

Örnek — bu prompt ne üretir?
Örnek girdi
notification gönderimi şu an API isteğinin içinde senkron gidiyor. kullanıcı kayıt olunca mail + sms aynı anda gönderiliyor, response 2-3 sn, bazen timeout oluyor. mobil ekip yavaşlıktan şikayetçi.

bir kuyruk yapısı düşünüyorum: event'i bir yere yaz, gönderimi arka planda yapalım. elimizde zaten Redis var (cache için kullanıyoruz), ana db PostgreSQL. ekip 4 backend, çok yeni altyapı kurmak istemeyiz, mümkünse mevcutla çözelim.

retry şart çünkü sms sağlayıcı ara ara patlıyor, o zaman kayıt isteği de fail oluyor. dakikada kaç mail gidiyor tam bilmiyorum. ileride push notification ve webhook da eklenecek belki. teslim tarihi net değil ama bu çeyrek içinde bir şey çıksın isteniyor.
Çıktı

1. Bağlam ve problem

  • Bugün kayıt akışında mail ve SMS bildirimleri API isteğinin içinde senkron gönderiliyor; yanıt 2-3 sn'ye çıkıyor, zaman zaman timeout oluyor.
  • Mobil ekip yavaş yanıttan şikâyetçi.
  • SMS sağlayıcı hata verdiğinde kayıt isteği de birlikte başarısız oluyor; yeniden deneme (retry) yok.
  • Hedef: gönderimi istekten ayırıp arka plana almak.

2. Hedefler ve kapsam dışı

Dahil:

  • Bildirim gönderimini asenkron kuyruğa taşımak.
  • Sağlayıcı hatasında otomatik retry.
  • Mevcut altyapıyla (Redis + PostgreSQL) çözmek; yeni servis kurulumunu minimumda tutmak.

Kapsam dışı:

  • Push notification ve webhook kanalları. VARSAYIM: "belki ileride" notundan hareketle bu turda dışarıda; tasarım bunları sonradan eklenebilir bırakmalı.
  • EKSIK: Bildirim şablonu / içerik yönetiminin bu işin parçası olup olmadığı belirtilmemiş.

3. Seçenekler

Seçenek A — Redis tabanlı kuyruk

  • Yaklaşım: Event'i mevcut Redis'e iş kuyruğu olarak yaz; ayrı bir worker süreci tüketip göndersin.
  • Artı: Redis zaten var; düşük gecikme; hazır kütüphaneler retry sağlıyor.
  • Eksi: Redis kalıcılık için yapılandırılmazsa restart'ta iş kaybı riski; ayrı worker süreci işletmek gerekir.
  • Maliyet/karmaşıklık: Orta-düşük.

Seçenek B — PostgreSQL iş tablosu (transactional outbox)

  • Yaklaşım: Kaydı ve "gönderilecek bildirim" satırını aynı transaction'da yaz; worker tabloyu yoklayıp gönderir, durumu günceller.
  • Artı: Kayıt ile bildirim atomik; iş kaybı riski düşük; yeni bileşen yok.
  • Eksi: Polling yükü DB'ye biner; yüksek hacimde Redis kadar ölçeklenmez.
  • Maliyet/karmaşıklık: Düşük.

4. Karşılaştırma

ÖlçütSeçenek A (Redis)Seçenek B (PostgreSQL)
PerformansYüksek, düşük gecikmeOrta; polling gecikmesi var
Bakım yüküWorker + Redis kalıcılık ayarıSadece worker; tanıdık DB
RiskKalıcılık ayarsızsa iş kaybıYüksek hacimde DB baskısı
Geçiş kolaylığıRedis mevcut, kütüphane eklenirEn kolay; tek tablo + worker

5. Önerilen karar ve gerekçe

  • Öneri: Seçenek B (PostgreSQL outbox) ile başla.
  • Gerekçe: "Yeni altyapı istemeyiz, mevcutla çözelim" kısıtına en uygunu; kayıt-bildirim atomikliği retry ihtiyacını da güvenli karşılıyor.
  • VARSAYIM: Mevcut hacim düşük/orta. Doğruysa DB polling yeterli.
  • EKSIK: Dakikadaki gönderim hacmi verilmedi; yüksekse (ör. binlerce/dk) Seçenek A'ya geçiş gerekebilir.

6. Riskler ve açık sorular

  • EKSIK: Beklenen ortalama ve tepe (peak) gönderim hacmi nedir?
  • EKSIK: "Bu çeyrek içinde" dışında net bir teslim tarihi var mı?
  • Retry kaç kez, hangi aralıkla denenecek? Kalıcı hata (dead-letter) nasıl ele alınacak?
  • Push/webhook eklenince aynı kuyruk mu kullanılacak; karar şimdiden mi verilmeli?
  • İdempotency: Aynı bildirimin iki kez gitmemesi nasıl garanti edilecek?

ÜRETİM: TEM 2026 · CLAUDE Bu kayıt eşlenmiş örnek girdi ve çıktı içerir. Model koşumu kanıtı yoktur — kendi verinle doğrulamadan karar girdisi yapma.

Kendi verinle çalıştır
Verini aşağıya yapıştır; prompt seninkiyle birleşip çalıştırmaya hazır tek bloğa dönüşsün. Sonra tek dokunuşla Claude ya da ChatGPT'de aç.
Hazır prompt — verini bekliyor
Sen deneyimli bir yazilim mimarisin. Sana bir teknik tasarim fikrinin ham notlarini verecegim. Gorevin, bu notlardan tartismaya hazir bir tasarim dokumani (RFC) iskeleti cikarmak.

Kurallar:
- Sadece verdigim bilgiyi kullan. Eksik olan yeri uydurma; o basligin altina "EKSIK: ..." yazip hangi bilginin gerektigini belirt.
- Tahmin yurutme. Bir varsayim ekliyorsan basina "VARSAYIM:" yaz.
- Tek cozum dayatma; en az iki secenek uret ve her birini ayni olcutlerle karsilastir.
- Kisa ve net yaz, madde isareti kullan.

Su basliklari doldur:
1. Baglam ve problem: bugun ne aksiyor, bu tasarim neyi cozecek.
2. Hedefler ve kapsam disi: neler dahil, acikca neler dahil degil.
3. Secenekler: en az 2 secenek. Her birinde yaklasim, arti, eksi, tahmini maliyet/karmasiklik.
4. Karsilastirma: secenekleri performans, bakim yuku, risk ve gecis kolayligi olcutlerinde tablo halinde karsilastir.
5. Onerilen karar ve gerekce: hangi secenek, neden.
6. Riskler ve acik sorular: karar oncesi netlesmesi gereken sorular.

Ham notlarim:
[buraya fikrini, kisitlari ve mevcut sistemi yapistir]

Yapıştırdığın veri tarayıcından çıkmaz — WhiteYaka'ya gönderilmez. Prompt panoya kopyalanır; açılan sohbete Ctrl/⌘ + V ile yapıştırırsın.

i Bu föy örnek girdi ve çıktı içerir; yapısal doğrulama ve ölçütlü prompt koşumu henüz kaydedilmedi.
← Yazılım & Teknik bölümü
← Tüm bölümler Sıradaki föy: Major sürüm yükseltmesinin changelog'unu breaking change özeti + adım adım geçiş listesine çevir →

Bülten kaydı kapalı.

Bu sayfa e-posta adresi toplamaz ve liste kaydı başlatmaz. 160 hamlenin tamamı giriş yapmadan açık.