PostgreSQL'de composite index kolon sırasını nasıl seçerim?
Tek bir (user_id, status, created_at DESC) composite index kurun: eşitlik kolonları başa, sıralama kolonu sona; kapsanan tekli indeksleri silin.
Sor Bakalım
Yazılım mimarisi, kariyer, PHP, Go ve geliştirme süreçleri üzerine merak ettiklerini sor; cevapları burada herkese açık paylaşıyorum. (Sayfa 7/8)
Aklına takılan ne varsa çekinme. Sorular bana ulaşır; uygun olanları cevaplayıp bu sayfada yayınlarım. E-postan kesinlikle yayınlanmaz.
Tek bir (user_id, status, created_at DESC) composite index kurun: eşitlik kolonları başa, sıralama kolonu sona; kapsanan tekli indeksleri silin.
Çoğu durumda single-flight lock ve TTL jitter yeter; XFetch'i recompute gerçekten pahalıyken açın ve her iki hâlde stale-while-revalidate ekleyin.
Duraklamaların ardındaki düşman tahsis hızıdır: pprof ile en çok tahsis edeni öldürün, hot path'i sync.Pool ile havuzlayın, GOGC ayarını en sona bırakın.
Önce memory_get_usage eğrisini çıkarın, service provider'ları bisect edip suçluyu daraltın, stateful singleton'ları Octane hook'larında sıfırlayın.
10.000 tenant'ta database-per-tenant operasyonel olarak ölçeklenmez; her tabloda tenant_id tutup izolasyonu Postgres Row-Level Security'ye gömün.
HMAC'i ham gövdede constant-time doğrulayın, hızlı 200 dönüp işi kuyruğa alın ve tekilliği event_id üzerindeki UNIQUE constraint'e yaptırın.
Ödemeyi gateway'de 5/20/100 ağırlıkla kaydırıp önce shadow'da doğrulayın; asıl iş tabloları ayırmak, arkasında anti-corruption layer ve outbox durur.
Fiyat değiştiği an aynı transaction ya da outbox içinde KV'ye write-through yapın veya key'i silin; kısa TTL ve versiyonlu key yalnızca emniyet ağıdır.
W3C Trace Context'te standartlaşıp propagation'ı OTel SDK'ya bırakın ve traceparent'ı kuyruk mesajının header'ına koyun; zincir orada kopuyor.
Çakışma runtime hatası değil adresleme planı sorunudur: Docker havuzunu daemon.json'da pinleyin, AllowedIPs'i DB subnet'ine kısın, rotaları kalıcı yapın.