వందల millions of accounts కి transaction history ను store & query చేయండి

Question

IT Interview Practice · Accepted Answer

**ledger ను account మరియు time ద్వారా partition చేయండి, ఇటీవలి data ను hot గా పాత data ను cold గా ఉంచండి, మరియు rows ను ఒక append-only immutable ledger గా పరిగణించండి — తద్వారా ఒక్క account యొక్క history ఒక చిన్న, indexed slice, ఎప్పుడూ billions of 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 ను bound చేస్తుంది.
- **Immutable ledger.** ఒక transaction ను ఎప్పుడూ `UPDATE` చేయవద్దు; corrections కొత్త reversing rows. ఇది ఒక audit trail, safe replication ను ఇస్తుంది, మరియు aggressively cache చేయనిస్తుంది (rows ఎప్పుడూ మారవు).
- **Hot/cold tiering.** low-latency reads కోసం చివరి ~3 months ను fast SSD/Postgres పై ఉంచండి; పాత partitions ను **S3/Parquet** (Athena/Trino ద్వారా queried) లేదా Glacier కి roll చేయండి. 95% queries ఇటీవలి data ను తాకుతాయి, కాబట్టి చాలా storage చవకగా ఉండవచ్చు.
- **Keyset pagination.** `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` తో page చేయండి — `OFFSET` కాదు. Offset skip అయిన rows ను scan చేసి discard చేస్తుంది; keyset నేరుగా index ను seek చేస్తుంది, ఒక్కో page కి O(1).

## ఇంటర్వ్యూ దృక్కోణం

ఇంటర్వ్యూయర్ **partition-key ఎంపిక** మరియు **pagination** ను పరిశీలిస్తారు. మంచి సమాధానాలు "partition by account" అంటాయి; గొప్ప సమాధానాలు deep pages వద్ద **keyset OFFSET ను ఎందుకు ఓడిస్తుందో**, **ledger ఎందుకు immutable** (auditability, no lock contention), మరియు **tiering** cost ను ఎలా తగ్గిస్తుందో వివరిస్తాయి. ఒక ఉచ్చు composite index తో ఒక్క giant table — index RAM లో fit అవ్వనంత వరకు పనిచేస్తుంది మరియు ప్రతి read disk-bound అవుతుంది.

## ట్రేడ్-ఆఫ్‌లు & వైఫల్యాలు

- **Partition key మార్చడం కష్టం.** account+time ను ముందుగానే ఎంచుకోండి; తర్వాత 100s of millions of rows ను re-partition చేయడం ఒక migration project.
- **Cross-account queries బాధపడతాయి.** "అన్ని accounts అంతటా total volume" ఇప్పుడు partitions అంతటా fan out అవుతుంది — వాటిని బదులుగా ఒక OLAP rollup కి push చేయండి.
- **Cold reads నెమ్మది.** Glacier నుండి 3-year-old statement fetch చేయడం నిమిషాలు పడుతుంది; user expectations ను set చేయండి లేదా request పై pre-warm చేయండి.
- **Hot partitions.** ఒక whale account లేదా ప్రస్తుత month ఒక hotspot కావచ్చు; sub-partition చేయండి లేదా cache చేయండి.
- **ఎప్పుడు కాదు:** millions of rows (వందల millions కాదు) ఒక indexed Postgres table లో fit అవుతాయి — మీకు అవసరం లేని tiering ను నిర్మించవద్దు. ఒక్క table యొక్క index memory లో fit అవ్వడం ఆగిపోయే scale వద్ద దీనికి చేరుకోండి.

ఆర్కిటెక్చర్

ఇది ఎలా పనిచేస్తుంది

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు & వైఫల్యాలు

సంబంధిత ప్రశ్నలు