রিমোট জব প্রিপারেশন — পর্ব ১০: সিস্টেম ডিজাইন ইন্টারভিউ
সিনিয়র লেভেলের সবচেয়ে ওজনদার রাউন্ড — অস্পষ্ট প্রশ্ন সংকুচিত করা, সংখ্যা দিয়ে হিসাব, ট্রেড-অফের ভাষা, অতিরিক্ত ইঞ্জিনিয়ারিংয়ের ফাঁদ, আর ব্যর্থতা ও অপারেশনের যে অংশে বেশিরভাগ ক্যান্ডিডেট চুপ হয়ে যায়।
সিনিয়র লেভেলের সবচেয়ে ওজনদার রাউন্ড — অস্পষ্ট প্রশ্ন সংকুচিত করা, সংখ্যা দিয়ে হিসাব, ট্রেড-অফের ভাষা, অতিরিক্ত ইঞ্জিনিয়ারিংয়ের ফাঁদ, আর ব্যর্থতা ও অপারেশনের যে অংশে বেশিরভাগ ক্যান্ডিডেট চুপ হয়ে যায়।
“একটা নোটিফিকেশন সিস্টেম ডিজাইন করো”
আল-বিরুনি প্রশ্নটা শুনে সাথে সাথে হোয়াইটবোর্ডে আঁকা শুরু করল: API Gateway, লোড ব্যালান্সার, তিনটা মাইক্রোসার্ভিস, Kafka, Redis, Cassandra, একটা worker pool, একটা CDN। আট মিনিটে বোর্ড ভরে গেল।
ইন্টারভিউয়ার জিজ্ঞেস করল, “দিনে কতগুলো নোটিফিকেশন যাবে?”
আল-বিরুনি থামল। সে জানে না। প্রশ্নটা সে করেনি।
ইন্টারভিউয়ার বলল, “ধরো দিনে ৫০ হাজার।”
দিনে ৫০ হাজার মানে সেকেন্ডে গড়ে একটারও কম। ওই বোর্ডের অর্ধেক জিনিস দরকার নেই — একটা PostgreSQL টেবিল আর একটা কিউ-ওয়ার্কারই যথেষ্ট, আর সেটা এক-দশমাংশ খরচে চলবে। আল-বিরুনি এমন একটা সমস্যার সমাধান করেছে যেটা তার সামনে ছিল না।
এই রাউন্ডে ইন্টারভিউয়ার তোমার আর্কিটেকচারের জ্ঞান মাপছে না — সেটা বই পড়লেই আসে। সে মাপছে তোমার সিদ্ধান্তের প্রক্রিয়া: তুমি কি জানতে চাও কত বড় সমস্যা? তুমি কি জানো প্রতিটা যন্ত্রাংশের একটা দাম আছে? তুমি কি সহজ সমাধানটা যুক্তি দিয়ে দাঁড় করাতে পারো?
১. ৪৫ মিনিটের বাজেট
সবচেয়ে সাধারণ ব্যর্থতা সময়ের অব্যবস্থাপনা — কেউ ২৫ মিনিট রিকোয়ারমেন্টে কাটায়, কেউ ডেটা মডেলে ঢুকে আর বেরোয় না। একটা ছক মাথায় রাখো:
| সময় | কাজ |
|---|---|
| ০–৭ | রিকোয়ারমেন্ট ও স্কোপ সংকুচিত করা |
| ৭–১২ | সংখ্যার হিসাব — লোড, স্টোরেজ, ব্যান্ডউইথ |
| ১২–১৭ | API ও ডেটা মডেল |
| ১৭–৩০ | হাই-লেভেল ডিজাইন, আর প্রতিটা অংশের কারণ |
| ৩০–৪০ | একটা অংশে গভীরে — ইন্টারভিউয়ারকে বেছে নিতে দাও |
| ৪০–৪৫ | ব্যর্থতা, স্কেলিংয়ের পরের ধাপ, আর অপারেশন |
সময় ফুরিয়ে গেলে জোর করে সব ঢোকানোর চেয়ে বলা ভালো: “বাকি যেটা আমি যোগ করতাম — ক্যাশিং লেয়ার আর ডেড-লেটার হ্যান্ডলিং — সময় থাকলে ওখানে যেতাম।” এতে বোঝা যায় তুমি জানো, শুধু সময় দাওনি।
২. অস্পষ্ট প্রশ্ন সংকুচিত করা — সবচেয়ে বড় সংকেত
প্রশ্নটা ইচ্ছাকৃতভাবেই অস্পষ্ট। “ইনস্টাগ্রাম ডিজাইন করো” — ৪৫ মিনিটে অসম্ভব, আর সেটাই পরীক্ষা: তুমি কি অসম্ভবটাকে সম্ভবের আকারে কেটে আনতে পারো?
যে প্রশ্নগুলো করবে, ক্রম অনুযায়ী:
- কারা ব্যবহার করবে, আর কী করতে? — মূল দুই-তিনটা ব্যবহার বেছে নাও, বাকিটা বাদ। “আমি ফিড পড়া আর পোস্ট করা ধরছি; ডিএম আর স্টোরি বাদ দিচ্ছি — ঠিক আছে?”
- কত বড়? — ইউজার সংখ্যা, দৈনিক সক্রিয়, প্রতি ইউজারের কার্যকলাপ।
- পড়া বেশি না লেখা বেশি? — এই একটা উত্তর পুরো ডিজাইন বদলে দেয়।
- লেটেন্সির প্রত্যাশা? — ২০০ms না ২ সেকেন্ড, দুটো সম্পূর্ণ ভিন্ন সিস্টেম।
- কনসিস্টেন্সি কতটা কড়া? — টাকার হিসাবে কড়া, লাইক-কাউন্টে না।
- কী সীমার বাইরে? — অথেনটিকেশন, বিলিং, অ্যানালিটিকস — স্পষ্ট করে বাদ দাও।
তারপর লিখে রাখো (বা বলে দাও) — “তাহলে আমি এই তিনটা জিনিস বানাচ্ছি, এই স্কেলে, এই লেটেন্সি বাজেটে।” এই এক বাক্যেই তুমি অস্পষ্টতা সামলানোর ক্ষমতা দেখিয়ে ফেললে, যেটা পর্ব ১-এর সিনিয়রিটির সংজ্ঞা।
৩. সংখ্যা দিয়ে হিসাব — মুখস্থ না, পদ্ধতি
ভয় পাওয়ার কিছু নেই; কেউ নিখুঁত হিসাব চায় না। যা চায় তা হলো মাপার অভ্যাস — কারণ সংখ্যাই ঠিক করে দেয় কোন সমাধান দরকার।
একটা সহজ পথ:
- দৈনিক সক্রিয় ইউজার × প্রতিজনের গড় অ্যাকশন = দৈনিক রিকোয়েস্ট
- দৈনিক ÷ ৮৬,৪০০ = গড় QPS; পিক ধরো গড়ের ৩–৫ গুণ
- প্রতি রেকর্ডের আকার × দৈনিক রেকর্ড = দৈনিক স্টোরেজ; × ৩৬৫ = বছরে
- রিড:রাইট অনুপাত — এটাই ক্যাশ, রেপ্লিকা আর ইনডেক্সের সিদ্ধান্ত চালায়
উদাহরণ, জোরে বলার মতো করে:
Let’s say 2 million daily actives, each posting twice and reading fifty times a day. That’s 4 million writes and 100 million reads per day — about 45 writes and 1,200 reads per second on average, so maybe 5,000 reads per second at peak. Reads dominate by about 25 to 1, so caching and read replicas will matter far more than write throughput. Each post record is maybe 500 bytes plus media, so text is only about 2 GB a day — the media store is the real storage problem, not the database.
এই এক প্যারাগ্রাফে তুমি চারটা সিদ্ধান্তের ভিত্তি তৈরি করে ফেললে। এখান থেকে প্রতিটা পছন্দের একটা কারণ আছে — আর “কেন” প্রশ্নের উত্তর তোমার কাছে আগে থেকেই আছে।
মনে রাখার মতো কয়েকটা আন্দাজ: মেমরি থেকে পড়া মাইক্রোসেকেন্ডে, SSD থেকে শত মাইক্রোসেকেন্ডে, একই অঞ্চলে নেটওয়ার্ক রাউন্ড-ট্রিপ মিলিসেকেন্ডের ঘরে, মহাদেশের এপার-ওপার একশো মিলিসেকেন্ডের ঘরে। এই মাত্রার পার্থক্যগুলোই বেশিরভাগ ডিজাইন সিদ্ধান্তের পেছনে থাকে — নিখুঁত সংখ্যা না।
৪. হাই-লেভেল ডিজাইন — প্রতিটা বাক্সের একটা কারণ
আঁকো সরল, বাঁ থেকে ডানে, তারপর প্রতিটা অংশের পক্ষে যুক্তি দাও। বাক্স যোগ করার আগে নিজেকে জিজ্ঞেস করো: এটা না থাকলে কী ভাঙবে? উত্তর না থাকলে বাক্সটা রেখো না।
এই ছবিটায় সাতটা অংশ, আর সাতটারই কারণ বলা যায় এক লাইনে। এটাই লক্ষ্য — বিশটা অংশের ছবি না যার অর্ধেক তুমি ব্যাখ্যা করতে পারবে না।
কিছু জায়গা যেখানে সিনিয়ররা আলাদা হয়:
- সিঙ্ক্রোনাস বনাম অ্যাসিঙ্ক্রোনাস — কোন কাজটা রিকোয়েস্টের ভেতরে থাকতেই হবে, আর কোনটা কিউতে যেতে পারে। ইমেইল পাঠানো, থাম্বনেইল বানানো, রিপোর্ট — কিউতে।
- ডেটা স্টোর নির্বাচন — “PostgreSQL কারণ আমার ট্রানজেকশন আর সেকেন্ডারি ইনডেক্স লাগবে” ভালো উত্তর; “MongoDB কারণ স্কেলেবল” খারাপ উত্তর।
- ক্যাশ কোথায়, আর ইনভ্যালিডেশন কীভাবে — ক্যাশ যোগ করা সহজ, ভুল ডেটা দেখানো সহজতর। TTL না ইভেন্ট-ভিত্তিক ইনভ্যালিডেশন, সেটা বলো।
- আইডেম্পোটেন্সি — রিট্রাই হলে ডাবল হবে কি না। পেমেন্ট বা অর্ডারের প্রশ্নে এটা না তুললে বড় ফাঁক।
৫. ট্রেড-অফের ভাষা
এই রাউন্ডে “সঠিক উত্তর” বলে কিছু নেই — আছে যুক্তিসহ পছন্দ। তাই তোমার প্রতিটা সিদ্ধান্ত এই আকারে বলো:
“আমি X নিচ্ছি। এতে পাচ্ছি A, হারাচ্ছি B। B গ্রহণযোগ্য কারণ [রিকোয়ারমেন্ট]। যদি [শর্ত] বদলাত, আমি Y নিতাম।”
শেষ বাক্যটাই সবচেয়ে দামি — এতে বোঝা যায় তুমি জানো সিদ্ধান্তটা প্রসঙ্গনির্ভর, নিয়ম না।
কয়েকটা ট্রেড-অফ যেগুলো প্রায় সব প্রশ্নে আসে:
| পছন্দ | পাও | হারাও |
|---|---|---|
| স্ট্রং কনসিস্টেন্সি | সঠিকতা, সহজ যুক্তি | লেটেন্সি, অ্যাভেইলেবিলিটি |
| ইভেন্টুয়াল কনসিস্টেন্সি | স্কেল, প্রাপ্যতা | জটিল এজ কেস, ব্যবহারকারীর বিভ্রান্তি |
| ক্যাশিং | লেটেন্সি ও খরচ | বাসি ডেটা, ইনভ্যালিডেশনের জটিলতা |
| অ্যাসিঙ্ক্রোনাস প্রসেসিং | দ্রুত রেসপন্স, বাফারিং | ডিবাগিং কঠিন, ক্রম ও ডুপ্লিকেটের সমস্যা |
| ডিনরমালাইজেশন | দ্রুত রিড | রাইট জটিল, ডেটা অসঙ্গতির ঝুঁকি |
| শার্ডিং | অনুভূমিক স্কেল | ক্রস-শার্ড কোয়েরি ও ট্রানজেকশন কঠিন |
৬. যেখানে বেশিরভাগ ক্যান্ডিডেট চুপ হয়ে যায়: ব্যর্থতা ও অপারেশন
শেষ দশ মিনিটে ইন্টারভিউয়ার প্রায়ই জিজ্ঞেস করে — “এই অংশটা মরে গেলে কী হবে?” এখানেই বই-পড়া প্রার্থী আর প্রোডাকশন-দেখা প্রার্থীর পার্থক্য বেরিয়ে আসে।
যেসব বিষয় নিজে থেকে তুললে তুমি আলাদা হয়ে যাও:
- আংশিক ব্যর্থতা — ডেটাবেস আছে কিন্তু কিউ নেই; তখন কি রিকোয়েস্ট ফেল করবে, নাকি ডিগ্রেড হয়ে চলবে?
- রিট্রাই ও ব্যাকঅফ — অন্ধ রিট্রাই একটা ছোট সমস্যাকে আউটেজ বানায়। এক্সপোনেনশিয়াল ব্যাকঅফ আর জিটার।
- ডেড-লেটার কিউ — যে মেসেজ বারবার ফেল করছে সেটা কোথায় যাবে, আর কে দেখবে।
- রেট লিমিট ও ব্যাকপ্রেশার — সিস্টেম ওভারলোডে কী করে: সারি বাড়ায়, নাকি না বলে?
- ডেটা মাইগ্রেশন ও ব্যাকফিল — নতুন ডিজাইনে যাওয়ার পথটা কী? ডুয়াল-রাইট, তারপর ব্যাকফিল, তারপর কাটওভার।
- রোলআউট ও রোলব্যাক — ফিচার ফ্ল্যাগ, ক্যানারি, আর ফিরে আসার পথ।
- মনিটরিং — কোন তিনটা মেট্রিক দেখলে বুঝবে সিস্টেম অসুস্থ? (সাধারণত: লেটেন্সি p99, ত্রুটির হার, কিউ ল্যাগ।)
অতিরিক্ত ইঞ্জিনিয়ারিং নম্বর কাটায়, যোগ করে না। Kafka, Kubernetes, মাইক্রোসার্ভিস আর মাল্টি-রিজিয়ন — এগুলো নাম নিলেই সিনিয়র শোনায় না; বরং হায়ারিং ম্যানেজারের সবচেয়ে বড় ভয়টা জাগিয়ে দেয় (পর্ব ১: “অপ্রয়োজনে জটিলতা আনবে না তো?”)।
সবচেয়ে শক্তিশালী বাক্যগুলোর একটা: “এই স্কেলে একটা PostgreSQL আর একটা ওয়ার্কারই যথেষ্ট। ট্রাফিক দশ গুণ হলে আমি প্রথমে রিড রেপ্লিকা যোগ করতাম, তারপর ক্যাশ; শার্ডিংয়ে যেতাম সবার শেষে।” এটা বলার সাহস আর যুক্তিই সিনিয়রিটি।
৭. নিজের কাজের সাথে জোড়া লাগানো
তোমার একটা সুবিধা আছে যেটা কম মানুষ ব্যবহার করে: তুমি সত্যিকারের সিস্টেম চালিয়েছ। যেখানেই পারো, নিজের অভিজ্ঞতা টেনে আনো —
“We had almost exactly this problem with checkout. We started with a synchronous call to the inventory service, and under sale traffic that turned into a queue of timeouts. Moving it to an event with a reconciliation job fixed the latency, but we then spent a month on duplicate-event handling. So if I take that path here, I’d want the idempotency key in the design from day one, not bolted on later.”
এই এক প্যারাগ্রাফ যেকোনো বই-পড়া উত্তরের চেয়ে ভারী, কারণ এটা যাচাইযোগ্য এবং এটা অভিজ্ঞতার দাগ — ইন্টারভিউয়ার নিজেও ওই দাগ চেনে।
সাইটের নোটস ট্র্যাকগুলো (/notes) এই রাউন্ডের প্রস্তুতির জন্যই — বিশেষত ক্যাশিং, ডেটাবেস ইন্টারনালস, রেপ্লিকেশন ও শার্ডিং, মেসেজিং, আর সিস্টেম ডিজাইন ট্র্যাক।
৮. তিনটা প্রশ্নের কাঠামো, সংক্ষেপে
“একটা URL শর্টনার ডিজাইন করো” — সহজ দেখায়, কিন্তু আসল পরীক্ষা রিড:রাইট অনুপাত (রিড হাজার গুণ বেশি), কী জেনারেশন (কাউন্টার বনাম হ্যাশ বনাম প্রি-জেনারেটেড রেঞ্জ), ক্যাশিং, আর কাস্টম alias-এর সংঘর্ষ।
“একটা নিউজ ফিড ডিজাইন করো” — মূল সিদ্ধান্ত fan-out on write বনাম on read, আর সেলিব্রিটি সমস্যা (দশ মিলিয়ন ফলোয়ারের পোস্ট)। সঠিক উত্তর প্রায়ই হাইব্রিড, আর সেটাই বলার সুযোগ।
“একটা পেমেন্ট/অর্ডার সিস্টেম ডিজাইন করো” — এখানে কনসিস্টেন্সি আর আইডেম্পোটেন্সি কেন্দ্রীয়, ডিস্ট্রিবিউটেড ট্রানজেকশনের বদলে outbox প্যাটার্ন, রিকনসিলিয়েশন জব, আর ব্যর্থ পেমেন্টের অবস্থা-যন্ত্র (state machine)।
তিনটার প্রস্তুতি একইভাবে: প্রশ্ন → সংখ্যা → সরল ডিজাইন → এক জায়গায় গভীরে → ব্যর্থতা।
এই সপ্তাহের কাজ
- নিজের কাজের একটা সিস্টেম সাদা কাগজে ৪৫ মিনিটে ডিজাইন করো, যেন তুমি ইন্টারভিউতে আছ — জোরে, ইংরেজিতে, সময় ধরে।
- ওই তিনটা ক্লাসিক প্রশ্নের প্রতিটার জন্য সংখ্যার হিসাবটা আগে থেকে করে রাখো, যাতে কলে দ্বিধা না হয়।
- একটা তালিকা লেখো: তোমার নিজের তিনটা ইনসিডেন্ট বা মাইগ্রেশন, প্রতিটা এক প্যারাগ্রাফে — এগুলোই ডিজাইন রাউন্ডে টেনে আনার উপাদান।
- সেই “অতিরিক্ত ইঞ্জিনিয়ারিং না করার” বাক্যটা অনুশীলন করো — সহজ সমাধানের পক্ষে যুক্তি দেওয়া কঠিন, কারণ এতে মনে হয় তুমি কম জানো। উল্টোটাই সত্যি।
পরের পর্ব — টেক-হোম অ্যাসাইনমেন্ট: কতটা সময় দেবে, কতটা বানাবে, README-তে কী লিখবে, আর কোন অ্যাসাইনমেন্ট ভদ্রভাবে ফিরিয়ে দেবে।