सैकड़ों करोड़ 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 पर लगती है — DB बाकी prune कर देता है। यह total size की परवाह किए बिना हर read को सीमित करता है।
- **Immutable ledger.** एक transaction को कभी `UPDATE` न करें; corrections नए reversing rows हैं। यह एक audit trail, safe replication देता है, और आपको आक्रामक रूप से cache करने देता है (rows कभी नहीं बदलते)।
- **Hot/cold tiering.** अंतिम ~3 महीने low-latency reads के लिए तेज़ SSD/Postgres पर रखें; पुराने partitions **S3/Parquet** (Athena/Trino के ज़रिए query) या Glacier में roll करें। 95% queries हाल के data पर लगती हैं, इसलिए अधिकांश storage सस्ता हो सकता है।
- **Keyset pagination.** `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` से page करें — `OFFSET` से नहीं। Offset skipped rows को scan और discard करता है; keyset index को सीधे seek करता है, प्रति page O(1)।

## इंटरव्यू का नज़रिया

Interviewer **partition-key चुनाव** और **pagination** परखता है। अच्छे जवाब कहते हैं "account से partition करें"; बढ़िया जवाब समझाते हैं कि deep pages पर **keyset OFFSET को क्यों पीटता है**, **ledger immutable क्यों है** (auditability, कोई lock contention नहीं), और **tiering** cost कैसे काटता है। एक जाल है एक composite index वाली एक विशाल table — यह तब तक काम करती है जब तक index RAM में न समाए और हर read disk-bound बन जाए।

## ट्रेड-ऑफ़ और 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 लाने में minutes लगते हैं; यूज़र अपेक्षाएं सेट करें या request पर pre-warm करें।
- **Hot partitions.** एक whale account या मौजूदा महीना एक hotspot हो सकता है; sub-partition या cache करें।
- **कब नहीं:** लाखों rows (सैकड़ों करोड़ नहीं) एक indexed Postgres table में समाते हैं — ऐसा tiering न बनाएं जिसकी ज़रूरत न हो। इसे उस scale पर अपनाएं जहां एक अकेली table का index memory में समाना बंद कर दे।

आर्किटेक्चर

यह कैसे काम करता है

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure

संबंधित प्रश्न