viral post-এর জন্য একটি real-time view/like counter কীভাবে বানাবেন?

Question

IT Interview Practice · Accepted Answer

একটি hot post-এ প্রতি event-এ কখনও `UPDATE posts SET views = views + 1` করবেন না — সেই একটি row একটি lock bottleneck হয়ে যায়। **Redis-এ increment করুন, প্রতি কয়েক সেকেন্ডে DB-তে batch-flush করুন**, এবং Redis থেকে count পড়ুন। DB durable total সংরক্ষণ করে, live traffic নয়।

## আর্কিটেকচার

```text
Client tap ─▶ API ─▶ Redis INCR views:{post}   (live, source of truth for reads)
                          │            └── dedup: SADD seen:{post} {user/ip}
                          ▼
                 every ~5s / N ops
              Flusher ─▶ UPDATE posts SET views = views + delta   (durable)
                          ▲
                 read path: GET Redis (fallback DB on miss)
```

## কম্পোনেন্ট ও ফ্লো

- **Redis INCR** write storm শোষণ করে। একটি একক `INCR views:{post}` atomic এবং একটি key-তে ১ লক্ষ+ ops/s সামলায় — একটি Postgres row-এর চেয়ে বহু গুণ বেশি। এই counter হলো *read*-এর source of truth, তাই দর্শকরা সংখ্যাটি সঙ্গে সঙ্গে বদলাতে দেখে।
- **like/unique view-এর জন্য dedup**: একটি raw counter refresh-কে double-count করে। `SADD seen:{post} {userId}` ব্যবহার করুন এবং কেবল তখনই `INCR` করুন যখন add নতুন; বিশাল স্কেলে সস্তা আনুমানিক unique-এর জন্য **HyperLogLog** (`PFADD`/`PFCOUNT`) ব্যবহার করুন — কয়েক KB ~২% error-এর মধ্যে লক্ষ লক্ষ unique আনুমানিক হিসাব করে।
- **Batched flusher** পর্যায়ক্রমে delta-টি DB-তে drain করে: `UPDATE posts SET views = views + delta`। প্রতি ৫সে বা প্রতি N increment-এ flush করা লক্ষ লক্ষ write-কে গুটিকয়েকে রূপান্তরিত করে — DB cold post ও analytics-এর জন্য durable total ধরে রাখে।
- **Read path** Redis থেকে পরিবেশন করে; একটি cache miss-এ এটি DB total পড়ে এবং Redis পুনরায় warm করে। Like-এর প্রতি-ইউজার state লাগে (*আমি* কি like করেছি), তাই কেবল একটি সংখ্যা নয়, set সংরক্ষণ করুন।

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

ইন্টারভিউয়াররা যাচাই করেন আপনি **count-এর জন্য eventual consistency** মেনে নেন কিনা। "ভালো" হলো "count cache করুন"; "দারুণ" হলো *write* buffer করা — বোঝা যে bottleneck হলো একটি hot row-এ write contention, read load নয়। তারা trade-টি যাচাই করেন: একটি আনুমানিক count কি গ্রহণযোগ্য? view count-এর জন্য, হ্যাঁ — কেউ ১,২০৩,৪২৮ বনাম ১,২০৩,৪৫০ খেয়াল করে না। ফাঁদটি হলো exact count নিয়ে দুশ্চিন্তা করা এবং একটি transaction-এর দিকে হাত বাড়ানো, যে lock আপনি এড়াচ্ছিলেন তা পুনরায় ফিরিয়ে আনা।

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

- **নির্ভুলতা বনাম throughput**: exact count-এর জন্য dedup set লাগে (memory-heavy); আনুমানিক HyperLogLog ক্ষুদ্র ও দ্রুত। প্রতি feature-এ বাছুন — like exact, view count আনুমানিক হতে পারে।
- **Durability**: Redis in-memory। একটি flush-এর আগে এটি মরলে, আপনি un-flushed delta হারান। AOF চালু করুন এবং flush window ছোট রাখুন (সেকেন্ড) যাতে ক্ষতি সীমাবদ্ধ থাকে; DB total প্লাস একটি ছোট gap একটি view counter-এর জন্য গ্রহণযোগ্য।
- **Hot key**: একটি viral post সমস্ত traffic একটি Redis key-তে কেন্দ্রীভূত করে। এটিকে `views:{post}:{0..9}`-এ shard করুন এবং read-এ sum করুন, অথবা hot key-কে একটি dedicated node-এ রুট করুন যাতে একটি post shard saturate করতে না পারে।

আর্কিটেকচার

কম্পোনেন্ট ও ফ্লো

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

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

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