Distributed cache কী এবং এর ব্যর্থতা কীভাবে সামলাবেন?

Question

IT Interview Practice · Accepted Answer

**Distributed cache একাধিক application instance-কে network দিয়ে data reuse করতে দেয়।** উদ্দেশ্য হলো ব্যয়বহুল কাজ পুনরাবৃত্তি এড়ানো, সঙ্গে freshness ও failure-এর স্পষ্ট নিয়ম রাখা।

ধরুন তিন backend instance একই product catalog পড়ছে। প্রতিটি process-এর cache হলে আলাদা কপি থাকে। Shared cache service-এ একটি instance value ভরলে অন্যরা ব্যবহার করতে পারে। Cache service নিজেও একাধিক node হতে পারে।

## 1. কী নিরাপদে cache করা যাবে ঠিক করুন

Data তৈরির খরচ ও কতটা পুরোনো চলবে দিয়ে শুরু করুন। Product description সামান্য দেরি সহ্য করতে পারে; purchase-এর final stock check authoritative data চাইতে পারে।

Tenant, language বা প্রাসঙ্গিক input-সহ পুরো result চিহ্নিত করে এমন key দিন। নইলে দ্রুত cache ভুল customer-এর data দিতে পারে। Durable business record-এর authoritative source database রাখুন, কারণ cache value হারাতে পারে।

## 2. Update design-এর আগে read path বুঝুন

প্রচলিত পদ্ধতি cache-aside: application cache দেখে, miss হলে database পড়ে, তারপর TTL নামের expiry-সহ result রাখে।

```text
Request -> Cache -> hit  -> Return value
                 -> miss -> Database -> Fill cache -> Return value
```

একই value অনেক request চাইলে এতে database read কমে। তবে network call ও আরেক dependency বাড়ে, তাই বাঁচানো কাজ এই খরচের চেয়ে বেশি হলেই cache উপকারী। দেখুন [Redis cache-aside](https://redis.io/docs/latest/develop/use-cases/cache-aside/)।

## 3. Update কীভাবে দৃশ্যমান হবে ঠিক করুন

Catalog-এ শুরু করার বাস্তব উপায় হলো database update commit করে cached product invalidate করা। পরের reader আবার load করে। কিন্তু race থাকে: reader commit-এর আগে পুরোনো value নিয়ে invalidation-এর পরে cache-এ রাখতে পারে।

TTL নতুন cached কপি কতক্ষণ টিকবে সীমিত করে; প্রতিটি read সঙ্গে সঙ্গে সর্বশেষ write দেখবে নিশ্চিত করে না। পুরোনো permission, price বা balance operation-এর নিয়ম ভাঙলে authoritative data যাচাই করুন বা স্পষ্ট guarantee-সহ version-aware update design করুন। Redis ব্যবহারেই সমাধান ধরে না নিয়ে business operation অনুযায়ী consistency বাছুন।

## 4. Cache miss যেন outage না হয়

Popular entry expire হলে অনেক caller একসঙ্গে database পড়তে পারে। এটি cache stampede। Cache outage বহু entry-তে একই সমস্যা করতে পারে।

- একই key-এর concurrent load একত্র করুন যাতে কম caller rebuild করে; coordination এক process না সব instance জুড়ে তা ঠিক করুন।
- Expiry time আলাদা করুন যাতে অনেক entry একসঙ্গে শেষ না হয়। এতে refresh work ছড়ায়, কিন্তু সব hot-key সমস্যা মেটে না।
- Business পুরোনো data অনুমতি দিলেই refresh চলাকালে আগের cached value দিন।
- ছোট cache timeout এবং সীমিত database fallback traffic রাখুন। কিছু কাজ reject করা database overload করে সব request fail করার চেয়ে নিরাপদ হতে পারে।

এই path ইচ্ছাকৃতভাবে পরীক্ষা করুন। স্বাভাবিক অবস্থায় high hit rate cache হারালে service কেমন চলবে তা বেশি বলে না।

## 5. প্রকৃত bottleneck অনুযায়ী scale করুন

Sharding key-গুলো cache node-এ ভাগ করে; replication availability বা read-এর জন্য copy রাখে। দুটো আলাদা সমস্যা সমাধান করে। Redis Cluster placement-এর জন্য hash slot ব্যবহার করে, তাই node যোগ করলেই একটি hot key-এর কাজ ভাগ হয় না। দেখুন [Redis Cluster specification](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/)।

Hit rate, latency, timeout, memory, eviction এবং database-এ আসা load দেখুন। Eviction মানে memory সামলাতে cache value সরিয়েছে; এটি TTL-এর আগেও হতে পারে। Cache entry-কে business data বা queued work-এর guaranteed durable storage ভাববেন না।

Catalog-এ আমি স্পষ্ট key-সহ cache-aside, freshness policy ও সুরক্ষিত fallback দিয়ে শুরু করব। মাপা capacity সমস্যা distribution সত্যিই সমাধান করতে পারলেই node বাড়াব। **ভালো cache design value থাকলে এবং না থাকলে বা ভুল হলে—সব অবস্থার আচরণ ব্যাখ্যা করে।**

1. কী নিরাপদে cache করা যাবে ঠিক করুন

2. Update design-এর আগে read path বুঝুন

3. Update কীভাবে দৃশ্যমান হবে ঠিক করুন

4. Cache miss যেন outage না হয়

5. প্রকৃত bottleneck অনুযায়ী scale করুন

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