शेकडो लाख 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" असते, म्हणून त्याच्याशी जुळण्यासाठी 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 करते. हे एकूण आकार कितीही असो प्रत्येक read बांधते.
- **Immutable ledger.** transaction कधीही `UPDATE` करू नका; दुरुस्त्या नवीन reversing rows आहेत. हे एक audit trail, safe replication देते, आणि तुम्हाला आक्रमकपणे cache करू देते (rows कधीही बदलत नाहीत).
- **Hot/cold tiering.** शेवटचे ~3 महिने कमी-latency reads साठी जलद 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 करते आणि टाकते; keyset थेट index seek करते, प्रति page O(1).

## मुलाखतीचा दृष्टिकोन

मुलाखत घेणारा **partition-key निवड** आणि **pagination** तपासतो. चांगली उत्तरे "account ने partition करा" म्हणतात; उत्तम उत्तरे deep pages वर **keyset OFFSET ला का हरवते**, **ledger immutable का** (auditability, no lock contention), आणि **tiering** cost कसे कमी करते हे समजावतात. एक सापळा म्हणजे composite index असलेली एक विशाल table — ती index RAM मध्ये न बसेपर्यंत चालते आणि मग प्रत्येक read disk-bound होते.

## तडजोडी आणि अपयश

- **Partition key बदलणे कठीण.** आधीच account+time निवडा; नंतर शेकडो लाख rows पुन्हा partition करणे एक migration project आहे.
- **Cross-account queries त्रास देतात.** "सर्व accounts मधील एकूण volume" आता partitions वर fan out होते — त्यांना ऐवजी OLAP rollup कडे push करा.
- **Cold reads slow आहेत.** Glacier मधून 3-वर्ष जुने statement आणण्यास मिनिटे लागतात; युजरच्या अपेक्षा सेट करा किंवा request वर pre-warm करा.
- **Hot partitions.** एक whale account किंवा चालू महिना एक hotspot असू शकतो; sub-partition किंवा cache करा.
- **कधी नको:** लाखो rows (शेकडो लाख नव्हे) एका indexed Postgres table मध्ये बसतात — तुम्हाला न लागणारे tiering बांधू नका. एका table चा index memory मध्ये न बसण्याच्या scale वर याकडे वळा.

आर्किटेक्चर

कसे कार्य करते

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

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