System Design Interview

System design interview তে কোনো একটা "সঠিক উত্তর" নেই। Interviewer দেখতে চায় তুমি কীভাবে চিন্তা করো: অস্পষ্ট সমস্যাকে কীভাবে স্পষ্ট করো, সংখ্যা দিয়ে যুক্তি দাও কিনা, trade-off বোঝো কিনা, আর একসাথে কাজ করার মতো মানুষ কিনা। এই অধ্যায়ে ৪৫ মিনিটের interview এর একটা পরীক্ষিত কাঠামো, সাধারণ ভুল, আর practice এর পরিকল্পনা।

#৪৫ মিনিটের কাঠামো

#১. Requirement (৫-৭ মিনিট): প্রশ্ন করো

সবচেয়ে বড় ভুল: প্রশ্ন শুনেই box আঁকতে শুরু করা। "WhatsApp design করো" শুনে জিজ্ঞেস করো:

• কোন feature গুলো এই আলোচনায়? (১-১ chat, group, media, call?) কোনগুলো বাদ?
• কত user? (DAU), কোন দেশ/অঞ্চল?
• কোনটা বেশি জরুরি: গতি, নির্ভরযোগ্যতা, সঠিকতা?
• কোনো বিশেষ সীমা? (mobile, encryption, নিয়মকানুন)

তারপর লিখে সারাংশ দাও: "তাহলে আমরা ১-১ আর group chat, delivery receipt, offline delivery design করবো, ৫ কোটি DAU, message হারাবে না, call বাদ।" Interviewer সম্মতি দিলে এগোও।

#২. হিসাব (৩-৫ মিনিট)

গোল সংখ্যায়, দ্রুত (Estimation): QPS (peak সহ), storage, bandwidth। আর হিসাব থেকে সিদ্ধান্ত বলো: "read এর চাপ ১০০ গুণ বেশি, তাই cache জরুরি।"

#৩. API (৩-৫ মিনিট)

প্রধান ৩-৫টা endpoint বা message, request/response এর গঠন। Idempotency key, pagination এর মতো খুঁটিনাটি উল্লেখ করলে ভালো ছাপ পড়ে।

#৪. Data model (৫ মিনিট)

প্রধান entity আর সম্পর্ক, কোন database কেন ("access pattern সরল আর write বিশাল, তাই wide-column")। Partition/shard key এর কথা।

#৫. High-level design (১০ মিনিট)

Box আর তীর: client, LB, service, cache, DB, queue, CDN। তারপর প্রধান flow ধাপে ধাপে বলো ("user post দিলে: ১... ২... ৩...")। এখানে সব কিছু নিখুঁত হওয়ার দরকার নেই, পুরো ছবিটা আগে।

#৬. Deep dive (১০-১৫ মিনিট)

সবচেয়ে কঠিন ২-৩টা অংশ বেছে গভীরে যাও (বা interviewer যেটা চায়)। প্রতিটায়:

• সমস্যা কী (bottleneck, race condition, hotspot)
• ২-৩টা বিকল্প, প্রতিটার ভালো-মন্দ
• কোনটা বাছলে আর কেন, এই requirement এর জন্য
• ভাঙলে কী হবে (failure), কীভাবে মাপবে (monitoring)

#কী শুনতে চায়

#সাধারণ ভুল

1. Requirement না জিজ্ঞেস করে শুরু
2. একটা অংশে আটকে যাওয়া: ৩০ মিনিট database schema নিয়ে, বাকি system এর কোনো ছবি নেই
3. বাড়াবাড়ি: ১০,০০০ user এর জন্য global multi-region
4. শুধু buzzword: "Kafka দেবো" কিন্তু কেন বা কীভাবে, বলতে না পারা
5. Trade-off না বলা: প্রতিটা বাছাই এর একটা দাম আছে, সেটা নিজে বলো
6. Failure ভুলে যাওয়া: "এই server বন্ধ হলে কী হবে?" নিজে আগেই তোলো
7. চুপচাপ থাকা: interviewer তোমার মাথার ভেতর দেখতে পায় না

#Practice এর পরিকল্পনা (মাস ১২)

#Practice এর প্রশ্ন

• Notification system (SMS, email, push; কোটি user)
• Rate limiter service (নিজেই একটা system)
• Distributed cache
• Search autocomplete (Google এর মতো)
• Online judge / coding contest platform
• Ticket booking (সিনেমা/বাস/ট্রেন, double booking ঠেকানো)
• Hotel booking
• Google Docs ধরনের collaborative editor
• Web crawler
• Leaderboard (live game)
• দেশের প্রেক্ষাপটে: পরীক্ষার ফল প্রকাশ, ঈদের বাস টিকিট বিক্রি, e-commerce এর flash sale

#Interview এর আগের দিন

• একটা ছোট cheat sheet আবার দেখো: latency এর সংখ্যা, ৬ ধাপ, প্রধান কৌশলগুলোর trade-off
• নিজের project এর ২-৩টা গল্প প্রস্তুত (সমস্যা, বিকল্প, সিদ্ধান্ত, ফল)
• Online interview হলে whiteboard tool (Excalidraw, Miro) আগে একবার চালিয়ে দেখো

#নিজেকে যাচাই করো

Interview এর প্রথম ৫ মিনিটে কী করা উচিত?

প্রশ্ন করে requirement স্পষ্ট করা: কোন feature, কত user, কোনটা বেশি জরুরি, কী বাদ। তারপর সারাংশ বলে interviewer এর সম্মতি নেওয়া।

Deep dive এ একটা সিদ্ধান্ত কীভাবে উপস্থাপন করবে?

সমস্যাটা বলো, ২-৩টা বিকল্প আর প্রতিটার ভালো-মন্দ, কোনটা বাছলে আর এই requirement এর জন্য কেন, আর সেই বাছাই এর দাম বা ঝুঁকি কী, ভাঙলে কী হবে।

Mobile developer হিসেবে system design interview তে কোন বিষয়গুলো তুলে আলাদা হতে পারো?

দুর্বল network এ retry আর idempotency, offline সমর্থন আর sync, push notification এর সীমা, পুরনো app version এর জন্য API compatibility, payload আর ছবির আকার, battery আর mobile data।