ਸੈਂਕੜੇ ਲੱਖਾਂ accounts ਲਈ transaction history store ਅਤੇ query ਕਰੋ

Question

IT Interview Practice · Accepted Answer

**ledger ਨੂੰ account ਅਤੇ time ਨਾਲ partition ਕਰੋ, ਹਾਲੀਆ data ਨੂੰ hot ਅਤੇ ਪੁਰਾਣੇ ਨੂੰ cold ਰੱਖੋ, ਅਤੇ rows ਨੂੰ ਇੱਕ append-only immutable ledger ਵਜੋਂ ਸਮਝੋ — ਤਾਂ ਜੋ ਇੱਕ single 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 ਕਰਦਾ ਹੈ। ਇਹ 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 ਮਹੀਨੇ fast SSD/Postgres ਉੱਤੇ ਰੱਖੋ; ਪੁਰਾਣੇ partitions ਨੂੰ **S3/Parquet** (Athena/Trino ਰਾਹੀਂ query) ਜਾਂ Glacier ਵੱਲ roll ਕਰੋ। 95% queries ਹਾਲੀਆ data ਨੂੰ hit ਕਰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਜ਼ਿਆਦਾਤਰ 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)।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਇੰਟਰਵਿਊਅਰ **partition-key choice** ਅਤੇ **pagination** ਪਰਖਦਾ ਹੈ। ਵਧੀਆ ਜਵਾਬ "account ਨਾਲ partition ਕਰੋ" ਕਹਿੰਦੇ ਹਨ; ਸ਼ਾਨਦਾਰ ਜਵਾਬ ਸਮਝਾਉਂਦੇ ਹਨ ਕਿ deep pages ਉੱਤੇ **keyset OFFSET ਨੂੰ ਕਿਉਂ ਹਰਾਉਂਦਾ ਹੈ**, **ledger immutable ਕਿਉਂ ਹੈ** (auditability, ਕੋਈ lock contention ਨਹੀਂ), ਅਤੇ **tiering** ਕੀਮਤ ਕਿਵੇਂ ਘਟਾਉਂਦੀ ਹੈ। ਇੱਕ ਫੰਦਾ ਹੈ ਇੱਕ composite index ਵਾਲੀ single giant table — ਇਹ ਤਦ ਤੱਕ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦ ਤੱਕ index RAM ਵਿੱਚ fit ਹੋਣਾ ਬੰਦ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਹਰ read disk-bound ਬਣ ਜਾਂਦਾ ਹੈ।

## ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ

- **Partition key ਬਦਲਣਾ ਔਖਾ ਹੈ।** ਪਹਿਲਾਂ ਤੋਂ account+time ਚੁਣੋ; ਬਾਅਦ ਵਿੱਚ 100s ਲੱਖਾਂ rows ਨੂੰ re-partition ਕਰਨਾ ਇੱਕ migration project ਹੈ।
- **Cross-account queries ਦੁੱਖ ਭੋਗਦੀਆਂ ਹਨ।** "ਸਾਰੇ accounts ਵਿੱਚ total volume" ਹੁਣ partitions ਦੇ ਪਾਰ fan out ਕਰਦੀ ਹੈ — ਉਹਨਾਂ ਨੂੰ ਇੱਕ OLAP rollup ਵੱਲ push ਕਰੋ।
- **Cold reads ਹੌਲੀ ਹਨ।** Glacier ਤੋਂ ਇੱਕ 3-ਸਾਲ-ਪੁਰਾਣਾ statement ਲਿਆਉਣ ਵਿੱਚ ਮਿੰਟ ਲੱਗਦੇ ਹਨ; user ਉਮੀਦਾਂ set ਕਰੋ ਜਾਂ request ਉੱਤੇ pre-warm ਕਰੋ।
- **Hot partitions.** ਇੱਕ whale account ਜਾਂ ਮੌਜੂਦਾ ਮਹੀਨਾ ਇੱਕ hotspot ਹੋ ਸਕਦਾ ਹੈ; ਇਸਨੂੰ sub-partition ਜਾਂ cache ਕਰੋ।
- **ਕਦੋਂ ਨਹੀਂ:** ਲੱਖਾਂ rows (ਸੈਂਕੜੇ ਲੱਖਾਂ ਨਹੀਂ) ਇੱਕ indexed Postgres table ਵਿੱਚ fit ਹੁੰਦੇ ਹਨ — ਓਹ tiering ਨਾ ਬਣਾਓ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਨਹੀਂ ਪਵੇਗੀ। ਇਸ ਵੱਲ ਓਸ scale ਉੱਤੇ ਹੱਥ ਵਧਾਓ ਜਿੱਥੇ ਇੱਕ single table ਦਾ index memory ਵਿੱਚ fit ਹੋਣਾ ਬੰਦ ਕਰ ਦੇਵੇ।

ਆਰਕੀਟੈਕਚਰ

ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ

ਸੰਬੰਧਿਤ ਸਵਾਲ