સેંકડો લાખો accounts માટે transaction history સ્ટોર અને query કરો

Question

IT Interview Practice · Accepted Answer

**ledger ને account અને time વડે partition કરો, તાજેતરના data ને hot અને જૂના data ને cold રાખો, અને rows ને append-only immutable ledger તરીકે ગણો — જેથી એક account ની history એ નાની, indexed slice હોય, ક્યારેય અબજો rows નું scan નહીં.** access pattern હંમેશા "એક account, એક date range" છે, તેથી તેને match કરવા partition કરો.

## આર્કિટેક્ચર

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

## તે કેવી રીતે કામ કરે છે

- **account + time વડે Partition.** account id ને N buckets માં hash કરો, પછી month વડે range-partition કરો. એક account/month માટે query બરાબર એક partition પર hit કરે છે — DB બાકીના prune કરે છે. આ કુલ size ને ધ્યાનમાં લીધા વગર દરેક read ને bound કરે છે.
- **Immutable ledger.** transaction ને ક્યારેય `UPDATE` ન કરો; corrections એ નવા reversing rows છે. આ audit trail, safe replication આપે છે, અને તમને આક્રમક રીતે cache કરવા દે છે (rows ક્યારેય બદલાતા નથી).
- **Hot/cold tiering.** low-latency reads માટે છેલ્લા ~3 months fast SSD/Postgres પર રાખો; જૂના partitions ને **S3/Parquet** (Athena/Trino દ્વારા queried) અથવા Glacier પર roll કરો. 95% queries તાજેતરના data પર hit કરે છે, તેથી મોટાભાગનું storage સસ્તું હોઈ શકે.
- **Keyset pagination.** `OFFSET` નહીં, `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` વડે page કરો. Offset skipped rows scan કરી discard કરે છે; keyset index ને સીધો seek કરે છે, પ્રતિ page O(1).

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર **partition-key choice** અને **pagination** probe કરે છે. Good answers "account વડે partition કરો" કહે છે; great answers સમજાવે છે કે **deep pages પર keyset OFFSET ને શા માટે હરાવે છે**, **ledger શા માટે immutable છે** (auditability, કોઈ lock contention નહીં), અને **tiering** કેવી રીતે cost ઘટાડે છે. Trap એ composite index સાથે એક વિશાળ table છે — તે ત્યાં સુધી કામ કરે છે જ્યાં સુધી index RAM માં fit થાય અને દરેક read disk-bound બને.

## Trade-offs અને failure

- **Partition key બદલવો મુશ્કેલ છે.** account+time પહેલેથી પસંદ કરો; પછીથી સેંકડો લાખો rows re-partition કરવું એ migration project છે.
- **Cross-account queries પીડાય છે.** "બધા accounts પર total volume" હવે partitions પર fan out કરે છે — તેને OLAP rollup પર push કરો.
- **Cold reads ધીમા છે.** Glacier માંથી 3-વર્ષ જૂનું statement fetch કરવામાં મિનિટો લાગે; user expectations set કરો અથવા request પર pre-warm કરો.
- **Hot partitions.** એક whale account અથવા વર્તમાન month hotspot હોઈ શકે; sub-partition કરો અથવા તેને cache કરો.
- **ક્યારે ન કરવું:** લાખો rows (સેંકડો લાખો નહીં) એક indexed Postgres table માં fit થાય છે — તમને જરૂર ન હોય તે tiering ન બનાવો. આ ત્યાં પહોંચો જ્યાં એક table નું index memory માં fit થવાનું બંધ કરે.

આર્કિટેક્ચર

તે કેવી રીતે કામ કરે છે

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure

સંબંધિત પ્રશ્નો