Yüz milyonlarca hesap için transaction geçmişini saklayın & sorgulayın

Question

IT Interview Practice · Accepted Answer

**Ledger'ı hesap ve zamana göre partition yapın, son veriyi hot ve eski veriyi cold tutun ve satırları append-only immutable bir ledger olarak ele alın — böylece tek bir hesabın geçmişi milyarlarca satırın taraması değil, küçük, index'lenmiş bir dilimdir.** Access pattern her zaman "bir hesap, bir tarih aralığı"dır, bu yüzden buna uyacak şekilde partition yapın.

## Mimari

```text
Write ─▶ Ledger table (append-only, immutable)
          partition by (account_hash, month)
              │
     ┌────────┴─────────┐
  HOT tier            COLD tier
  last 3 mo           older
  Postgres/SSD        S3/Parquet, Glacier
     │                    │
  index-seek        keyset paginate ──▶ API (account+range)
```

## Nasıl çalışır

- **Hesap + zamana göre partition.** Hesap id'sini N bucket'a hash'leyin, sonra ay'a göre range-partition yapın. Bir hesap/ay için bir sorgu tam olarak bir partition'a çarpar — DB geri kalanını budar. Bu, toplam boyuttan bağımsız olarak her okumayı sınırlar.
- **Immutable ledger.** Bir transaction'ı asla `UPDATE` etmeyin; düzeltmeler yeni ters satırlardır. Bu bir audit trail, güvenli replication verir ve agresif cache'lemenize izin verir (satırlar asla değişmez).
- **Hot/cold tiering.** Düşük latency okumalar için son ~3 ayı hızlı SSD/Postgres'te tutun; daha eski partition'ları **S3/Parquet**'e (Athena/Trino aracılığıyla sorgulanan) veya Glacier'a yuvarlayın. Sorguların %95'i son veriye çarpar, bu yüzden çoğu storage ucuz olabilir.
- **Keyset pagination.** `OFFSET` değil, `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` ile sayfalayın. Offset, atlanan satırları tarar ve atar; keyset index'i doğrudan seek eder, sayfa başına O(1).

## Mülakat perspektifi

Mülakatı yapan kişi **partition-key seçimini** ve **pagination**'ı yoklar. İyi cevaplar "hesaba göre partition" der; harika cevaplar **keyset'in derin sayfalarda neden OFFSET'i yendiğini**, **ledger'ın neden immutable olduğunu** (auditability, lock contention yok) ve **tiering**'in maliyeti nasıl kestiğini açıklar. Bir tuzak, composite index'li tek bir dev tablodur — index artık RAM'e sığmayana ve her okuma disk-bound olana kadar çalışır.

## Ödünleşimler & hata

- **Partition key değiştirmesi zordur.** Önceden hesap+zaman seçin; yüz milyonlarca satırı sonradan yeniden partition yapmak bir migration projesidir.
- **Cross-account sorgular acı çeker.** "Tüm hesaplar arası toplam hacim" artık partition'lar arası fan-out yapar — bunları bunun yerine bir OLAP rollup'a itin.
- **Cold okumalar yavaştır.** Glacier'dan 3 yıllık bir ekstre getirmek dakikalar alır; kullanıcı beklentilerini ayarlayın veya talep üzerine önceden ısıtın.
- **Hot partition'lar.** Bir balina hesap veya mevcut ay bir hotspot olabilir; onu sub-partition yapın veya cache'leyin.
- **Ne zaman yapılmamalı:** milyonlarca satır (yüz milyonlarca değil) tek bir index'lenmiş Postgres tablosuna sığar — ihtiyaç duymayacağınız tiering'i inşa etmeyin. Bunu, tek bir tablonun index'inin belleğe sığmayı bıraktığı ölçekte kullanın.

Mimari

Nasıl çalışır

Mülakat perspektifi

Ödünleşimler & hata

İlgili sorular