करोडौं account का लागि transaction history भण्डारण र query गर्नुहोस्

Question

IT Interview Practice · Accepted Answer

**ledger लाई account र time अनुसार partition गर्नुहोस्, भर्खरको data hot र पुरानो data cold राख्नुहोस्, र row हरूलाई append-only immutable ledger मान्नुहोस् — ताकि एउटा account को history अर्बौं row को scan होइन, सानो, indexed slice होस्।** 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 bucket मा hash गर्नुहोस्, अनि महिना अनुसार range-partition गर्नुहोस्। एउटा account/month को query ठ्याक्कै एउटा partition हान्छ — DB ले बाँकी prune गर्छ। यसले कुल आकार जस्तोसुकै होस्, हरेक read सीमित गर्छ।
- **Immutable ledger.** transaction लाई कहिल्यै `UPDATE` नगर्नुहोस्; सुधार नयाँ reversing row हुन्। यसले audit trail, सुरक्षित replication दिन्छ, र आक्रामक रूपमा cache गर्न दिन्छ (row कहिल्यै बदलिँदैनन्)।
- **Hot/cold tiering.** low-latency read का लागि अन्तिम ~3 महिना छिटो SSD/Postgres मा राख्नुहोस्; पुराना partition लाई **S3/Parquet** (Athena/Trino मार्फत query) वा Glacier मा roll गर्नुहोस्। 95% query भर्खरको data हान्छ, त्यसैले अधिकांश storage सस्तो हुन सक्छ।
- **Keyset pagination.** `OFFSET` होइन, `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` ले page गर्नुहोस्। Offset ले skip गरिएका row scan र discard गर्छ; keyset ले सिधै index seek गर्छ, प्रति page O(1)।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारले **partition-key छनौट** र **pagination** probe गर्छन्। राम्रो उत्तरले "account अनुसार partition" भन्छ; उत्कृष्टले **किन deep page मा keyset ले OFFSET जित्छ**, किन **ledger immutable छ** (auditability, lock contention छैन), र **tiering** ले कसरी लागत घटाउँछ व्याख्या गर्छ। एउटा जाल composite index सहितको एउटै विशाल table हो — index RAM मा नअटाउँदासम्म काम गर्छ, अनि हरेक read disk-bound हुन्छ।

## ट्रेड-अफ र failure

- **Partition key बदल्न गाह्रो.** सुरुमै account+time छान्नुहोस्; पछि करोडौं row re-partition गर्नु एउटा migration project हो।
- **Cross-account query दुःखी हुन्छ.** "सबै account को कुल volume" अब partition मा fan out हुन्छ — त्यसलाई OLAP rollup मा पठाउनुहोस्।
- **Cold read ढिलो.** Glacier बाट 3-वर्ष पुरानो statement ल्याउन मिनेट लाग्छ; user अपेक्षा सेट गर्नुहोस् वा request मा pre-warm गर्नुहोस्।
- **Hot partition.** एउटा whale account वा चालु महिना hotspot हुन सक्छ; sub-partition गर्नुहोस् वा cache गर्नुहोस्।
- **कहिले नगर्ने:** लाखौं row (करोडौं होइन) एउटा indexed Postgres table मा अटाउँछन् — तपाईंलाई नचाहिने tiering नबनाउनुहोस्। एउटै table को index memory मा नअटाउने scale मा यो तिर पुग्नुहोस्।

आर्किटेक्चर

कसरी काम गर्छ

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure

सम्बन्धित प्रश्नहरू