سینکڑوں ملین accounts کے لیے transaction history store اور query کریں

Question

IT Interview Practice · Accepted Answer

**ledger کو account اور time سے partition کریں، حالیہ ڈیٹا hot اور پرانا ڈیٹا cold رکھیں، اور rows کو ایک append-only immutable ledger کے طور پر لیں — تاکہ ایک واحد account کی history ایک چھوٹا، indexed slice ہو، کبھی اربوں rows کا scan نہیں۔** access pattern ہمیشہ "ایک account، ایک date range" ہے، لہٰذا اس سے میل کھانے کے لیے 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 کرتا ہے۔ یہ ہر read کو total size سے قطع نظر محدود کرتا ہے۔
- **Immutable ledger۔** کبھی کسی transaction کو `UPDATE` نہ کریں؛ corrections نئی reversing rows ہوتی ہیں۔ یہ ایک audit trail، محفوظ replication دیتا ہے، اور آپ کو جارحانہ انداز میں cache کرنے دیتا ہے (rows کبھی نہیں بدلتیں)۔
- **Hot/cold tiering۔** آخری تقریباً 3 مہینے low-latency reads کے لیے تیز SSD/Postgres پر رکھیں؛ پرانے partitions کو **S3/Parquet** (Athena/Trino کے ذریعے queried) یا Glacier میں roll کریں۔ 95% queries حالیہ ڈیٹا کو hit کرتی ہیں، لہٰذا زیادہ تر storage سستا ہو سکتا ہے۔
- **Keyset pagination۔** `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` سے page کریں — `OFFSET` سے نہیں۔ Offset چھوڑی گئی rows scan اور discard کرتا ہے؛ keyset سیدھا index seek کرتا ہے، فی page O(1)۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والا **partition-key کا انتخاب** اور **pagination** جانچتا ہے۔ اچھے جواب کہتے ہیں "account سے partition کرو"؛ عمدہ جواب بتاتے ہیں کہ **deep pages پر keyset OFFSET کو کیوں مات دیتا ہے**، **ledger immutable کیوں ہے** (auditability، کوئی lock contention نہیں)، اور **tiering** لاگت کیسے کم کرتی ہے۔ ایک جال ایک composite index کے ساتھ ایک بڑی table ہے — یہ تب تک کام کرتی ہے جب تک index RAM میں نہ سما سکے اور ہر read disk-bound ہو جائے۔

## توازن اور ناکامی

- **Partition key بدلنا مشکل ہے۔** account+time پہلے چنیں؛ بعد میں سینکڑوں ملین rows کو دوبارہ partition کرنا ایک migration project ہے۔
- **Cross-account queries تکلیف دہ ہیں۔** "تمام accounts میں کل حجم" اب partitions میں پھیل جاتا ہے — انہیں ایک OLAP rollup کی طرف push کریں۔
- **Cold reads سست ہیں۔** Glacier سے 3 سال پرانا statement لانا منٹ لیتا ہے؛ صارف کی توقعات طے کریں یا درخواست پر pre-warm کریں۔
- **Hot partitions۔** ایک whale account یا موجودہ مہینہ ایک hotspot ہو سکتا ہے؛ اسے sub-partition یا cache کریں۔
- **کب نہیں:** لاکھوں rows (سینکڑوں ملین نہیں) ایک indexed Postgres table میں سماتی ہیں — وہ tiering نہ بنائیں جس کی آپ کو ضرورت نہیں۔ اس کی طرف اُس پیمانے پر بڑھیں جہاں ایک واحد table کا index memory میں سمانا بند کر دے۔

فن تعمیر

یہ کیسے کام کرتا ہے

انٹرویو کا نقطۂ نظر

توازن اور ناکامی

متعلقہ سوالات