Hifadhi na query transaction history kwa mamia ya mamilioni ya accounts

Question

IT Interview Practice · Accepted Answer

**Partition ledger kwa account na time, weka data ya hivi karibuni hot na ya zamani cold, na tendea rows kama append-only immutable ledger — ili history ya account moja iwe slice ndogo yenye index, si scan ya rows bilioni.** Access pattern daima ni "account moja, date range", hivyo partition ilingane nayo.

## Usanifu

```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)
```

## Jinsi inavyofanya kazi

- **Partition kwa account + time.** Hash account id kuwa N buckets, kisha range-partition kwa mwezi. Query ya account/mwezi mmoja hupiga partition moja tu — DB hukata iliyobaki. Hii huweka mipaka kwa kila read bila kujali ukubwa wa jumla.
- **Immutable ledger.** Kamwe usifanye `UPDATE` kwa transaction; marekebisho ni reversing rows mpya. Hii hutoa audit trail, replication salama, na hukuruhusu ku-cache kwa nguvu (rows hazibadiliki kamwe).
- **Hot/cold tiering.** Weka miezi ~3 ya mwisho kwenye SSD/Postgres ya haraka kwa reads za low-latency; hamisha partitions za zamani kwenda **S3/Parquet** (zinazoqueryiwa kupitia Athena/Trino) au Glacier. 95% ya queries hupiga data ya hivi karibuni, hivyo storage nyingi inaweza kuwa nafuu.
- **Keyset pagination.** Page kwa `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — si `OFFSET`. Offset huscan na kutupa rows zilizorukwa; keyset huseek index moja kwa moja, O(1) kwa page.

## Mtazamo wa mahojiano

Mhojiwa huchunguza **chaguo la partition-key** na **pagination**. Majibu mazuri husema "partition kwa account"; bora sana hueleza **kwa nini keyset hushinda OFFSET** kwenye deep pages, kwa nini **ledger ni immutable** (auditability, hakuna lock contention), na jinsi **tiering** inavyopunguza gharama. Mtego ni jedwali moja kubwa lenye composite index — hufanya kazi hadi index isipotoshea RAM na kila read huwa disk-bound.

## Maelewano na hitilafu

- **Partition key ni ngumu kubadilisha.** Chagua account+time mapema; ku-repartition mamia ya mamilioni ya rows baadaye ni mradi wa migration.
- **Cross-account queries huteseka.** "Jumla ya volume kuvuka accounts zote" sasa hufanya fan-out kuvuka partitions — sukuma hizo kwenye OLAP rollup badala yake.
- **Cold reads ni polepole.** Kupata statement ya miaka 3 kutoka Glacier huchukua dakika; weka matarajio ya mtumiaji au pre-warm kwa ombi.
- **Hot partitions.** Whale account au mwezi wa sasa unaweza kuwa hotspot; sub-partition au cache.
- **Wakati usifanye:** mamilioni ya rows (si mamia ya mamilioni) hutoshea jedwali moja la Postgres lenye index — usijenge tiering usiyohitaji. Kimbilia hili kwenye scale ambapo index ya jedwali moja huacha kutoshea memory.

Usanifu

Jinsi inavyofanya kazi

Mtazamo wa mahojiano

Maelewano na hitilafu

Maswali yanayohusiana