শত শত মিলিয়ন 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 একটি ছোট, indexed slice, কখনও শত কোটি row-এর 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 bucket-এ hash করুন, তারপর month দিয়ে range-partition করুন। একটি account/month-এর একটি query ঠিক একটি partition-এ আঘাত করে — DB বাকিটা prune করে। এটি total size নির্বিশেষে প্রতিটি read সীমাবদ্ধ করে।
- **Immutable ledger.** একটি transaction কখনও `UPDATE` করবেন না; সংশোধন হলো নতুন reversing row। এটি একটি audit trail, নিরাপদ replication দেয়, এবং আপনাকে আক্রমণাত্মকভাবে cache করতে দেয় (row কখনও বদলায় না)।
- **Hot/cold tiering.** low-latency read-এর জন্য শেষ ~৩ মাস দ্রুত SSD/Postgres-এ রাখুন; পুরনো partition **S3/Parquet**-এ (Athena/Trino দিয়ে query করা) বা Glacier-এ roll করুন। ৯৫% 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** যাচাই করেন। ভালো উত্তর বলে "account দিয়ে partition করুন"; দারুণ উত্তর ব্যাখ্যা করে **কেন deep page-এ keyset OFFSET-কে হারায়**, কেন **ledger immutable** (auditability, no lock contention), এবং কীভাবে **tiering** খরচ কমায়। একটি ফাঁদ হলো একটি composite index সহ একটি বিশাল table — এটি কাজ করে যতক্ষণ না index আর RAM-এ আঁটে এবং প্রতিটি read disk-bound হয়।

## ট্রেড-অফ ও ব্যর্থতা

- **Partition key পাল্টানো কঠিন।** আগেভাগে account+time বাছুন; পরে ১০০ মিলিয়ন row re-partition করা একটি migration প্রকল্প।
- **Cross-account query কষ্ট পায়।** "সব account জুড়ে total volume" এখন partition জুড়ে fan out করে — সেগুলোকে বরং একটি OLAP rollup-এ push করুন।
- **Cold read ধীর।** Glacier থেকে একটি ৩-বছরের পুরনো statement আনতে মিনিট লাগে; ইউজার প্রত্যাশা সেট করুন বা request-এ pre-warm করুন।
- **Hot partition.** একটি whale account বা current month একটি hotspot হতে পারে; sub-partition বা cache করুন।
- **কখন নয়:** মিলিয়ন row (শত মিলিয়ন নয়) একটি indexed Postgres table-এ আঁটে — যে tiering লাগবে না তা বানাবেন না। যে স্কেলে একটি একক table-এর index memory-তে আঁটা বন্ধ করে সেখানে এটির দিকে হাত বাড়ান।

আর্কিটেকচার

কীভাবে কাজ করে

ইন্টারভিউ দৃষ্টিভঙ্গি

ট্রেড-অফ ও ব্যর্থতা

সম্পর্কিত প্রশ্ন