Requirement আর trade-off — functional, non-functional আর ভালো নকশার মাপকাঠি

১ · “একটি ছবি শেয়ারের অ্যাপ বানান” — অস্পষ্ট অনুরোধ থেকে requirement

পর্ব ০১-এ system design-এর বড় ছবিটা দেখেছেন; এবার প্রথম কাজ। ধরুন ইন্টারভিউতে, বা অফিসের মিটিংয়ে, আপনাকে বলা হলো: “একটি ছবি শেয়ারের অ্যাপ বানান।” একজন প্রকৌশলী সঙ্গে সঙ্গে বোর্ডে বাক্স আঁকলেন — load balancer, Kafka, Redis, দশটি microservice. আরেকজন আগে প্রশ্ন করলেন: “কারা ব্যবহার করবেন? কতজন? ভিডিও লাগবে? ছবি হারালে কতটা ক্ষতি?” অভিজ্ঞ ইন্টারভিউয়ার দ্বিতীয়জনকেই বেছে নেবেন, কারণ উত্তর না জেনে আঁকা নকশা ঠিক না ভুল, তা বিচারের কোনো মাপকাঠিই থাকে না।

Functional requirement (FR) বলে সিস্টেম কী করবে — যেমন “ব্যবহারকারী ছবি আপলোড করতে পারবেন।” Non-functional requirement (NFR) বলে কাজগুলো কতটা ভালোভাবে হবে — কত দ্রুত, কতজনের জন্য, কত সময় চালু থেকে, ডেটা না হারিয়ে, কতটা নিরাপদে আর কত খরচে; একে quality attribute-ও বলা হয়। সহজ পরীক্ষা: বাক্যটি বাদ দিলে একটি feature-ই হারায়? তাহলে FR. Feature থাকে, কিন্তু ধীর বা ঝুঁকিপূর্ণ হয়? তাহলে NFR.

নিচে পাঁচটি প্রশ্নে পূর্ণ তালিকা দাঁড়ানো দেখুন। উত্তরগুলো “ধরা যাক” ধরনের অনুমান; বাস্তবে আসে product দল আর আগের metric থেকে।

এই ID-গুলো (F1–F4, N1–N6, C1) পুরো পর্বে ফিরে আসবে। একটি সূক্ষ্মতা খেয়াল করুন: N5-এ like-এর সংখ্যা পিছিয়ে থাকলে চলে, কিন্তু কেউ block বা private করলে তা সঙ্গে সঙ্গে কার্যকর হতে হবে — একই সিস্টেমে দুই রকম consistency (অংশ ৫)।

২ · Load বর্ণনা — চাহিদাকে কয়েকটি সংখ্যায় বাঁধা

“আমাদের সিস্টেম কি scale করবে?” — প্রশ্নটির অর্থ নেই, যতক্ষণ না বলা হয় কোন চাপে। Martin Kleppmann-এর বই Designing Data-Intensive Applications (O’Reilly, ২০১৭) এই চিন্তাটি জনপ্রিয় করেছে: আগে বর্তমান চাপকে কয়েকটি সংখ্যায় বর্ণনা করুন — বইটি এদের বলে load parameter — তারপর জিজ্ঞেস করুন, “সংখ্যাটি দ্বিগুণ হলে কী ঘটবে?” (বইটির উদাহরণ মূল বইয়ে দেখে নেবেন; এখানে ধারণাটি আমাদের মতো করে সাজানো।) সবচেয়ে প্রচলিত পাঁচটি:

Fan-out দুই অর্থে আসে: social fan-out — একটি পোস্ট সব follower-এর feed-এ পৌঁছানো (অংশ ৬); আর request fan-out — একটি অনুরোধ ভেতরে ২০টি সার্ভিসকে ডাকে, আর সবচেয়ে ধীরটিই পুরো অনুরোধকে ধীর করে (tail latency, পর্ব ০৪)।

R মানে প্রতি লেখায় কয়টি পড়া (১০:১ হলে R = ১০), তাই প্রতি (R + ১)-টি অনুরোধে ১টি লেখা; ৮৬,৪০০ = এক দিনের সেকেন্ড। আমাদের অনুমানে: ১ কোটি × ৫০ = দিনে ৫০ কোটি অনুরোধ; ÷ ৮৬,৪০০ ≈ প্রতি সেকেন্ডে ৫,৭৮৭টি; এর ১১ ভাগের ১ ভাগ লেখা ≈ ৫২৬, পড়া ≈ ৫,২৬১. Peak factor (সবচেয়ে ব্যস্ত সময়ের হার ÷ সারাদিনের গড়) ৩ ধরলে peak-এ লেখা ≈ ১,৫৭৮ আর পড়া ≈ ১৫,৭৮৩. এই সংখ্যা থেকে storage আর সার্ভারের হিসাব পর্ব ০৩-এ।

Workload-এর চরিত্র: পড়া-ভারী, লেখা-ভারী, আর ভিড়ের সময়

Read-heavy সিস্টেমে পড়া অনেক বেশি — সংবাদের সাইট, পণ্যের ক্যাটালগ, social feed, পরীক্ষার ফলের পাতা; প্রধান অস্ত্র cache, CDN আর read replica. Write-heavy সিস্টেমে লেখা বেশি বা প্রায় সমান — chat, log সংগ্রহ, ride-sharing-এ কয়েক সেকেন্ড পরপর গাড়ির অবস্থান (পর্ব ৫৮); এখানে cache কম কাজে আসে, লাগে লেখার পথ ভাগ করা (পর্ব ২৩), queue আর লেখায় দক্ষ storage engine (পর্ব ১৯)।

চাহিদা সময় ধরেও বদলায় — রাতে কম, সন্ধ্যায় বেশি, আর ঋতু ধরে (seasonality). চেনা উদাহরণ: ঈদের আগে অনলাইন কেনাকাটা আর বাস-ট্রেনের টিকিট; SSC বা HSC-র ফল প্রকাশের মুহূর্ত, যখন লাখো পরীক্ষার্থী আর অভিভাবক প্রায় একই মিনিটে পাতাটি খোলেন; বড় ক্রিকেট ম্যাচের শেষ ওভারে streaming-এর হঠাৎ ভিড়। শেষ দুটিতে চাহিদা ধীরে বাড়ে না, একটি মুহূর্তে লাফ দেয়। সবাই একসাথে একই জিনিস চাইলে তাকে বলে thundering herd (পর্ব ১৮, ২৯)।

নিচের ক্যালকুলেটর চারটি পরিস্থিতির গড় আর peak read-write QPS বের করে; নিজের সংখ্যা বসিয়ে দেখুন।

// Load from requirements for a photo-sharing app.
// Every input below is an ASSUMPTION, not a measurement: put in your own numbers.
const DAY = 86400;                                  // seconds in a day
const f = (x) => Math.round(x).toLocaleString("en-US").padStart(13);

function load(name, dau, actionsPerUser, readsPerWrite, peakFactor) {
  const avg = (dau * actionsPerUser) / DAY;         // average requests per second
  const w = avg / (readsPerWrite + 1);              // 1 write for every readsPerWrite reads
  const r = avg - w;
  console.log(name.padEnd(21) + f(r) + f(w) + f(r * peakFactor) + f(w * peakFactor));
}

console.log("scenario".padEnd(21) + ["read/s", "write/s", "peak read/s", "peak write/s"]
            .map((h) => h.padStart(13)).join(""));
//   name                   DAU     actions/user/day  reads per write  peak factor
load("A: normal day",       10e6,   50,               10,              3);
load("B: festival evening", 10e6,   50,               10,              6);
load("C: chat-like, 1:1",   10e6,   50,               1,               3);
load("D: users doubled",    20e6,   50,               10,              3);

scenario                    read/s      write/s  peak read/s peak write/s
A: normal day                5,261          526       15,783        1,578
B: festival evening          5,261          526       31,566        3,157
C: chat-like, 1:1            2,894        2,894        8,681        8,681
D: users doubled            10,522        1,052       31,566        3,157

৩ · Non-functional requirement-এর তালিকা — সংজ্ঞা আর মাপার উপায়

NFR-এর নামগুলো চেনা, কিন্তু আলোচনায় প্রায়ই গুলিয়ে যায়। নিচে প্রতিটির সংজ্ঞা আর কীভাবে মাপবেন — যা মাপা যায় না, তার লক্ষ্যও ঠিক করা যায় না।

Availability, reliability আর durability — তিনটি আলাদা প্রশ্ন

Availability: এখন চাইলে সেবা পাব কি? Reliability: সময় ধরে, ত্রুটি সত্ত্বেও, সঠিক উত্তর দিয়ে যাবে কি? Durability: জমা নিশ্চিত হওয়া ডেটা কখনো হারাবে কি? প্রতি মিনিটে ১ সেকেন্ড বন্ধ হওয়া সার্ভিসের availability প্রায় ৯৮.৩৩%, কিন্তু মাঝপথ থেকে আবার শুরুর (resume) সুবিধা না থাকলে এক মিনিটের বেশি সময়ের আপলোড কখনো শেষ হবে না — reliability খুব কম। Database এক ঘণ্টা বন্ধ অথচ ডেটা অক্ষত: availability কমেছে, durability নয়। শুধু memory-তে রাখা cache সবসময় সাড়া দেয়, কিন্তু restart-এ সব হারায় — available, durable নয়। “Nines”-এর অঙ্ক পর্ব ০৫-এ, percentile পর্ব ০৪-এ।

Consistency — strong বনাম eventual, প্রথম পরিচয়

একই ডেটার একাধিক কপি থাকলে (replication), এক কপিতে লেখার পর অন্য কপি থেকে পড়লে কী দেখব? Strong consistency: লেখা সম্পন্ন হওয়ার পর প্রতিটি পড়া সেটি দেখবে, যেন একটিই কপি। Eventual consistency: নতুন লেখা থামলে কপিগুলো শেষ পর্যন্ত মিলবে, কিন্তু মাঝে পুরোনো মান দেখা যেতে পারে — এই দেরি replication lag. Strong-এর দাম latency আর availability, eventual-এর দাম পুরোনো মান। পুরো তত্ত্ব পর্ব ৪০-এ (CAP, PACELC আর consistency model).

Maintainability, security-privacy আর cost

Kleppmann-এর বই maintainability-কে তিন ভাগে দেখায়: operability — চালানোর দল যেন সহজে নজর রাখতে, সারাতে আর deploy করতে পারে (metric, log, নির্দেশিকা); simplicity — অপ্রয়োজনীয় জটিলতা কম; evolvability — নতুন requirement এলে বদলানো সহজ। আজ দ্রুত কিন্তু কেউ বোঝে না এমন সিস্টেম এক বছর পরে সবচেয়ে দামি হয়।

Security ও privacy শুরু থেকেই NFR. দুটি নীতি নকশাকে সরাসরি বদলায়। Data minimisation: যে তথ্য কাজে লাগে না, তা সংগ্রহই নয় — যা নেই, তা ফাঁসও হয় না। Retention: কোন তথ্য কতদিন থাকবে, আর মেয়াদ শেষে cache, replica, backup-সহ সব কপি থেকে কীভাবে মুছবে। ইউরোপের GDPR (২০১৮ থেকে কার্যকর)-এর মতো আইনে দুটিই মূলনীতি; দেশভেদে নিয়ম আলাদা হতে পারে, তাই নির্দিষ্ট আইনি দায় compliance বিশেষজ্ঞের সাথে মিলিয়ে নিন (প্রতিরক্ষার কৌশল পর্ব ৫২-এ)। আর cost-ও requirement: খরচ মাপুন প্রতি ১,০০০ অনুরোধে বা প্রতি সক্রিয় ব্যবহারকারীতে, তাহলে বৃদ্ধির সাথে বিল কীভাবে বাড়বে, আগেই দেখা যায় (পর্ব ০৩)।

৪ · Constraint আর assumption — নকশার সীমানা আর অনুমান

Requirement বলে কোথায় পৌঁছাতে হবে; constraint বলে কোন পথ বন্ধ, অন্তত এখন; আর assumption হলো যা সত্য ধরে নিয়েছি, কিন্তু যাচাই করিনি। কেউ বললেন “Kubernetes চাই” — এটা requirement, constraint, না নিছক পছন্দ? প্রশ্নটা করলেই অনেক তর্ক মেটে।

Assumption নম্বর দিয়ে লিখে রাখুন। “A1: বেশিরভাগ ব্যবহারকারী ধীর মোবাইল নেটওয়ার্কে” — সত্য হলে ছবি ছোট রাখা আর কয়েকটি resolution বানানো জরুরি। “A2: পড়া:লেখা ≈ ১০:১” — ভুল হলে cache-নির্ভর নকশা দুর্বল হবে। লিখে না রাখা অনুমান লুকানো ঝুঁকি; তাই পাশে লিখুন কীভাবে যাচাই হবে — প্রথম মাসের metric, ছোট load test বা জরিপ।

৫ · Trade-off-এর তালিকা — প্রতিটি সুবিধার একটি দাম

Trade-off মানে একটি গুণ পেতে আরেকটি কিছুটা ছাড়া। ঢাকায় একই গন্তব্যের কয়েকটি পথ: flyover দ্রুত কিন্তু ঘুরপথ, গলি ছোট কিন্তু অনিশ্চিত, মেট্রো নির্ভরযোগ্য কিন্তু স্টেশন পর্যন্ত হাঁটা। কোনটি “সেরা”, তা নির্ভর করে আজ কী দরকার। ভালো প্রকৌশলী প্রতিটি সিদ্ধান্তে বলতে পারেন: কী পেলাম, কী দাম দিলাম, আর কোন requirement-এর কারণে দামটি গ্রহণযোগ্য।

প্রতিটি সারিতে “কোনটি ভালো?” প্রশ্নের উত্তর একই — নির্ভর করে, আর নির্ভর করে requirement-এর ওপর। এবার একটি trade-off ধাপে ধাপে: একই প্রশ্ন, দুই ধরনের ডেটা, দুই উত্তর।

৬ · Push বনাম pull — একটি trade-off সংখ্যায় মাপা

Feed বানানোর দুটি মৌলিক উপায়। Fan-out on write (push): পোস্ট করলেই সেটি প্রত্যেক follower-এর আগে-তৈরি feed-এ লেখা হয়; feed খোলা মানে নিজের তালিকাটি পড়া। Fan-out on read (pull): পোস্ট থাকে লেখকের নিজের তালিকায়; feed খোলার সময় যাঁদের follow করেন, তাঁদের প্রত্যেকের তালিকা পড়ে মেলানো হয়।

কোনটি সস্তা — একটি ছোট প্রমাণ

ধরুন N জন ব্যবহারকারী, তাঁদের মধ্যে মোট E-টি follow সম্পর্ক (গড়ে প্রত্যেকের E/N জন follower). প্রত্যেকে দিনে p-টি পোস্ট করেন আর L-বার feed খোলেন। সরল মডেলে একটি feed-এ একটি লেখা, বা একটি তালিকা একবার পড়া — প্রতিটিকে একটি কাজ ধরি:

• Push: লেখা = pE (মোট pN-টি পোস্ট, প্রতিটি গড়ে E/N জনের feed-এ); পড়া = LN (প্রতিবার নিজের একটি তালিকা)।
• Pull: লেখা = pN (প্রতিটি পোস্ট একবার); পড়া = LE (প্রতিবার গড়ে E/N জনের তালিকা)।

গড়ে প্রত্যেকের একজনের বেশি follower থাকলে E > N, তাই চিহ্নটি ঠিক করে (p − L): মোট কাজের হিসাবে push সস্তা ঠিক তখনই, যখন মানুষ পোস্ট করার চেয়ে বেশিবার feed খোলেন (L > p). Social অ্যাপে প্রায় সবসময় তাই। কিন্তু মোট সংখ্যা একটি বিপদ লুকায়: push-এ একটি পোস্টের খরচ লেখকের follower সংখ্যার সমান, তাই লাখো follower-ওয়ালা একজনের একটি পোস্ট এক মুহূর্তে লাখো লেখা তৈরি করে। প্রচলিত সমাধান hybrid: সাধারণ ব্যবহারকারীর পোস্ট push, খুব জনপ্রিয়দের (“celebrity”) পোস্ট pull — feed খোলার সময় এনে মিশিয়ে দেওয়া। Kleppmann-এর বইয়ের প্রথম অধ্যায়ে, Twitter-এর ২০১২ সালের একটি প্রকাশ্য বক্তৃতার তথ্য ধরে, ঠিক এই পথ — pull থেকে push, তারপর hybrid — বর্ণনা করা আছে। পুরো নকশা পর্ব ৫৬-এ।

নিচের মডেল একটি seed-দেওয়া (প্রতিবার একই ফল দেয় এমন) এলোমেলো সংখ্যার উৎস দিয়ে ১০,০০০ জনের follower সংখ্যা বানায় — বেশিরভাগের কয়েক ডজন, অল্প কয়েকজনের হাজার হাজার — তারপর দুই ধরনের দিনে তিন মডেলের দৈনিক কাজ গোনে:

// Feed cost model: fan-out-on-write (push) vs fan-out-on-read (pull) vs hybrid.
// A seeded PRNG (mulberry32) makes the follower distribution identical on every run.
function mulberry32(a) {
  return function () {
    a = (a + 0x6D2B79F5) | 0;
    let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const rand = mulberry32(42), N = 10000, T = 1000;   // T: "celebrity" = more than 1000 followers
// Heavy tail (Pareto, capped): most users have a few dozen followers, a few have thousands.
const fol = Array.from({ length: N }, () =>
  Math.min(N - 1, Math.floor(10 / (1 - rand()) ** (1 / 1.1))));
const edges = fol.reduce((a, b) => a + b, 0);       // total follow relations
const celebs = fol.filter((x) => x > T), celebEdges = celebs.reduce((a, b) => a + b, 0);
const maxPush = Math.max(...fol), maxHybrid = Math.max(...fol.filter((x) => x <= T));
console.log(`users ${N}, follows ${edges}, avg followers ${(edges / N).toFixed(1)}, celebrities ${celebs.length}`);
console.log(`one post, worst case: push ${maxPush} writes, hybrid ${maxHybrid} writes`);
const g = (x) => Math.round(x).toLocaleString("en-US").padStart(12);
function day(label, postsPerUser, loadsPerUser) {
  const posts = N * postsPerUser, loads = N * loadsPerUser;
  const rows = [  // [model, writes/day, reads/day]
    ["push (on write)", postsPerUser * edges, loads],                  // copy post into every follower's feed
    ["pull (on read)", posts, loads * (edges / N)],                    // read each followee's list per load
    ["hybrid", postsPerUser * (edges - celebEdges + celebs.length),    // push normal users only,
               loads * (1 + celebEdges / N)],                          // pull celebrities at read time
  ];
  console.log(`\n${label}: ${posts} posts/day, ${loads} feed loads/day`);
  console.log("model".padEnd(16) + ["writes/day", "reads/day", "total"].map((h) => h.padStart(12)).join(""));
  for (const [m, w, r] of rows) console.log(m.padEnd(16) + g(w) + g(r) + g(w + r));
}
day("W1 read-heavy feed", 0.2, 20);
day("W2 many posts, few loads", 3, 1);

users 10000, follows 598669, avg followers 59.9, celebrities 65
one post, worst case: push 9999 writes, hybrid 1000 writes

W1 read-heavy feed: 2000 posts/day, 200000 feed loads/day
model             writes/day   reads/day       total
push (on write)      119,734     200,000     319,734
pull (on read)         2,000  11,973,380  11,975,380
hybrid                81,659   4,008,780   4,090,439

W2 many posts, few loads: 30000 posts/day, 10000 feed loads/day
model             writes/day   reads/day       total
push (on write)    1,796,007      10,000   1,806,007
pull (on read)        30,000     598,669     628,669
hybrid             1,224,885     200,439   1,425,324

৭ · অগ্রাধিকার আর weighted decision matrix — সিদ্ধান্তকে স্পষ্ট করা

সব NFR একসাথে সর্বোচ্চ রাখা যায় না — সবচেয়ে কম latency, সবচেয়ে কম খরচ আর সবচেয়ে কড়া consistency একসাথে চাওয়া মানে কিছুই না চাওয়া। তাই প্রথম কাজ অগ্রাধিকার ঠিক করা। একটি জনপ্রিয় পদ্ধতি MoSCoW (১৯৯০-এর দশকে Dai Clegg-এর তৈরি বলে পরিচিত): প্রতিটি requirement-কে চারটি ঝুড়ির একটিতে রাখুন।

নকশার বিকল্পগুলোর মধ্যে বাছতে কাজে লাগে weighted decision matrix: (১) বিকল্প লিখুন; (২) মাপকাঠি নিন NFR থেকে; (৩) অগ্রাধিকার থেকে weight দিন, যোগফল ১; (৪) প্রতিটি মাপকাঠিতে ১ থেকে ৫ নম্বর দিন; (৫) নম্বর × weight যোগ করুন; (৬) weight একটু বদলে দেখুন, বিজয়ী বদলায় কি না। নিচে photo metadata আর feed রাখার তিনটি বিকল্প; নম্বর একই, কিন্তু তিন দলের তিন রকম অগ্রাধিকার:

// Weighted decision matrix: 3 options for photo metadata + feed storage.
// Scores 1 (poor) .. 5 (excellent) are the team's own judgement; weights sum to 1.
const criteria = ["latency", "scalability", "consistency", "cost", "simplicity"];
const options = {
  "A: one SQL DB + replicas": [3, 2, 5, 5, 5],
  "B: NoSQL cluster":         [4, 5, 2, 2, 2],
  "C: SQL + cache":           [5, 3, 4, 3, 3],
};
const weightSets = {
  "small team, tight budget": [0.15, 0.10, 0.20, 0.30, 0.25],
  "fast-growing feed":        [0.35, 0.30, 0.10, 0.15, 0.10],
  "huge scale, stale OK":     [0.25, 0.45, 0.05, 0.15, 0.10],
};
console.log("criteria: " + criteria.join(", "));
for (const [label, w] of Object.entries(weightSets)) {
  const sum = w.reduce((a, b) => a + b, 0);
  if (Math.abs(sum - 1) > 1e-9) throw new Error(label + ": weights must sum to 1");
  const ranked = Object.entries(options)
    .map(([name, s]) => [name, s.reduce((acc, x, i) => acc + x * w[i], 0)])
    .sort((a, b) => b[1] - a[1]);
  console.log("\n" + label + "  [" + w.join(", ") + "]");
  for (const [name, total] of ranked) console.log("  " + name.padEnd(26) + total.toFixed(2));
  console.log("  winner: " + ranked[0][0] + " (ahead by " +
              (ranked[0][1] - ranked[1][1]).toFixed(2) + ")");
}

criteria: latency, scalability, consistency, cost, simplicity

small team, tight budget  [0.15, 0.1, 0.2, 0.3, 0.25]
  A: one SQL DB + replicas  4.40
  C: SQL + cache            3.50
  B: NoSQL cluster          2.60
  winner: A: one SQL DB + replicas (ahead by 0.90)

fast-growing feed  [0.35, 0.3, 0.1, 0.15, 0.1]
  C: SQL + cache            3.80
  B: NoSQL cluster          3.60
  A: one SQL DB + replicas  3.40
  winner: C: SQL + cache (ahead by 0.20)

huge scale, stale OK  [0.25, 0.45, 0.05, 0.15, 0.1]
  B: NoSQL cluster          3.85
  C: SQL + cache            3.55
  A: one SQL DB + replicas  3.15
  winner: B: NoSQL cluster (ahead by 0.30)

৮ · সিদ্ধান্ত লিখে রাখা — Architecture Decision Record (ADR)

ছয় মাস পরে নতুন একজন সদস্য জিজ্ঞেস করলেন: “like-এর সংখ্যা দেরিতে বদলায় — বাগ? ঠিক করে দিই?” যিনি সিদ্ধান্তটি নিয়েছিলেন, তিনি অন্য চাকরিতে; চ্যাটের আলোচনা হারিয়ে গেছে। কোড বলে কী করা হয়েছে, কেন — তা কোথাও নেই।

Architecture Decision Record (ADR)-এর ধারণা জনপ্রিয় হয় Michael Nygard-এর ২০১১ সালের একটি ব্লগ লেখা থেকে: প্রতিটি গুরুত্বপূর্ণ নকশা-সিদ্ধান্তের জন্য এক-দুই পাতার ছোট লেখা, কোডের সাথেই (যেমন docs/adr/ ফোল্ডারে), ক্রমিক নম্বরসহ। মূল লেখায় অংশ পাঁচটি — Title, Context, Decision, Status আর Consequences; অনেক টেমপ্লেটে Status থাকে শিরোনামের ঠিক পরে, কেউ কেউ “বিবেচিত বিকল্প” অংশও যোগ করেন। পুরোনো ADR মোছা হয় না: সিদ্ধান্ত বদলালে নতুন ADR লেখা হয়, আর পুরোনোটির Status হয় “superseded”. নিচে অংশ ৫-এর like-সিদ্ধান্তটিই ADR হয়ে লেখা হচ্ছে।

# ADR-0004: Like-এর সংখ্যায় eventual consistency
তারিখ: 2026-10-28 · সিদ্ধান্তদাতা: backend দল

## Status


## Context
- F4: একজন একটি ছবিতে একবারই like দিতে পারবেন।
- N2: feed-এর p99 < 500 ms. N5: like-এর সংখ্যা কয়েক সেকেন্ড
  পিছিয়ে থাকলে চলবে (product দলের সাথে নিশ্চিত করা)।
- জনপ্রিয় ছবিতে এক সেকেন্ডে বহু like; প্রতিটিতে একই সারির
  counter বদলালে সেই সারিতে lock-এর লাইন পড়ে।
- বিবেচিত বিকল্প: (১) একই transaction-এ counter বাড়ানো,
  (২) প্রতিবার গুনে দেখানো, (৩) আলাদা counter পরে বাড়ানো।

## Decision
আমরা প্রতিটি like লিখব likes(user_id, photo_id) টেবিলে, এই দুই
কলামে unique key দিয়ে। দেখানোর সংখ্যা থাকবে আলাদা counter-এ,
queue-র মাধ্যমে asynchronous-ভাবে বাড়ানো; সেটি সর্বোচ্চ কয়েক
সেকেন্ড পিছিয়ে থাকতে পারে।

## Consequences
+ like দেওয়া দ্রুত; জনপ্রিয় ছবিতেও এক সারিতে lock-এর ভিড় নেই।
+ একজনের দুবার like unique key-ই আটকাবে।
− সংখ্যা কিছুক্ষণ পিছিয়ে থাকবে; প্রতি রাতে counter মেলানোর
  একটি কাজ (reconciliation job) লাগবে।
− queue আর worker — নজর রাখার নতুন দুটি অংশ।
− like-সংখ্যার ভিত্তিতে কখনো টাকা দেওয়া হলে আবার ভাবতে হবে।

(পরে বদলালে: ফাইলটি মুছবেন না; Status-এ লিখুন
 “superseded by ADR-00xx”, আর নতুন ADR-এ এটির উল্লেখ দিন।)

নিজের প্রকল্পে শুরু করতে নিচের ফাঁকা টেমপ্লেটটি কপি করে নিতে পারেন:

# ADR-NNNN: <ছোট শিরোনাম>
তারিখ: YYYY-MM-DD · সিদ্ধান্তদাতা: …

## Status
প্রস্তাবিত / গৃহীত / বাতিল / superseded by ADR-NNNN

## Context
কোন requirement (ID), কোন মাপা সংখ্যা, কোন সীমা — আর বিবেচিত বিকল্পগুলো

## Decision
আমরা … করব

## Consequences
+ যা পেলাম
− যে দাম দিলাম; কোন অবস্থায় আবার ভাবতে হবে

Context-কে requirement-এর ID দিয়ে বাঁধলে requirement বদলানোর সময় প্রভাবিত সিদ্ধান্তগুলো খুঁজে পাওয়া যায়। পঞ্চাশ পাতার নকশা-দলিল কেউ পড়ে না, এক পাতার ADR পড়ে।

৯ · Requirement থেকে নকশা — প্রতিটি বাক্সের একটি কারণ

এবার সব জোড়া লাগাই। ছবি দেখার অনুরোধ যায় CDN-এ; বাকি অনুরোধ load balancer হয়ে কয়েকটি stateless API সার্ভারে। তৈরি-feed থাকে cache-এ, ছবির ফাইল object storage-এ, আর ধীর কাজ (thumbnail, feed-এ ছড়ানো) যায় message queue হয়ে worker-এর কাছে। প্রতিটি বাক্সের নিচে লেখা, কোন requirement তাকে দরকারি করেছে; যে বাক্সের পাশে কোনো ID বসে না, সেটি সম্ভবত over-engineering.

১০ · AI-এর যুগে requirement আর trade-off

AI-এর কাছে “একটি ছবি শেয়ারের অ্যাপের system design” চাইলে কয়েক সেকেন্ডে সুন্দর নকশা আসে — load balancer, Kafka, Redis, দশটি microservice. কিন্তু নকশাটি কোন requirement-এর উত্তর, AI তা জানে না; সে একটি “গড়” প্রশ্নের “গড়” উত্তর দেয়। প্রশ্ন করা, সংখ্যা বসানো আর দাম লেখার কাজটি আপনার; সেখানে AI ভালো সহকারী — প্রশ্নের তালিকা মনে করায়, বিকল্প খোঁজে, ADR-এর খসড়া লেখে।

AI-এর দেওয়া নকশা গ্রহণের আগে — চেকলিস্ট

• প্রতিটি অংশ একটি requirement-এর ID-তে ফিরে যায়; না গেলে বাদ দিয়েছি (over-engineering নয়)
• QPS আর peak-এর অঙ্ক নিজে, বা অংশ ২-এর ক্যালকুলেটরে, আবার করেছি
• প্রতিটি অংশ বিকল হলে কোথায় ডেটা হারায় বা পুরোনো মান দেখায় — তালিকা করেছি
• “consistency” কোন অর্থে বলা, পরিষ্কার করেছি; পণ্যের limit আর দাম official documentation-এ মিলিয়েছি
• ছোট load test বা simulation চালিয়ে মূল অনুমানটি যাচাই করেছি