Fundamentalsপড়তে ১০ মিনিট লাগবে

সিস্টেম ডিজাইন কী? (What is System Design?)

আপনার ব্যবহৃত প্রতিটি অ্যাপের পেছনের ব্লুপ্রিন্ট

scope:ফাউন্ডেশনাল (Foundational)difficulty:বিগিনার (Beginner)

সিস্টেম ডিজাইন কেন গুরুত্বপূর্ণ? (Why System Design Matters)

কল্পনা করুন আপনি একটা ট্রি-হাউস বানাচ্ছেন। আপনি চাইলেই কিছু কাঠ আর পেরেক ঠুকে কাজ শুরু করে দিতে পারেন। কিন্তু যদি আপনি চান যে সেটা ৫ জন মানুষের ভার নেবে, ঝড়ে টিকে থাকবে এবং একটা দড়ির মই থাকবে — তাহলে আপনার একটা পরিকল্পনা (Plan) দরকার।

সিস্টেম ডিজাইন হলো সেই পরিকল্পনা, তবে সফটওয়্যারের জন্য। এক লাইন কোড লেখার আগেই কোনো কিছু কীভাবে বানানো হবে, তার সিদ্ধান্ত নেওয়ার শিল্পই হলো সিস্টেম ডিজাইন। আপনি কোন ডাটাবেস ব্যবহার করবেন? কীভাবে লাখ লাখ ইউজার একই সময়ে কানেক্ট করবে? রাত ৩টায় সার্ভার ক্র্যাশ করলে কী হবে?

আপনার পছন্দের প্রতিটি অ্যাপ — ইনস্টাগ্রাম, ইউটিউব, গুগল ম্যাপস — শুরু হয়েছিল কারো হোয়াইটবোর্ডে আঁকা কিছু বাক্স আর তীরচিহ্ন দিয়ে। সেই স্কেচটাই হলো সিস্টেম ডিজাইন।

▸ একটিমাত্র সার্ভার সব রিকোয়েস্ট হ্যান্ডেল করছে

▸ ট্রাফিক বাড়ছে — সার্ভার হিমশিম খাচ্ছে

ফাংশনাল বনাম নন-ফাংশনাল রিকোয়ারমেন্ট (Functional vs Non-Functional Requirements)

কোনো কিছুর ডিজাইন করার আগে আপনাকে জানতে হবে আপনি কী বানাচ্ছেন এবং সেটা কতটা ভালোভাবে কাজ করতে হবে। এগুলোকে দুটো ভাগে ভাগ করা যায়:

ফাংশনাল রিকোয়ারমেন্ট (Functional requirements) — সিস্টেম কী করে। "ইউজাররা ছবি আপলোড করতে পারবে।" "ইউজাররা মেসেজ পাঠাতে পারবে।" এগুলোকে বক্সের গায়ে লেখা ফিচারের মতো ভাবতে পারেন।
নন-ফাংশনাল রিকোয়ারমেন্ট (Non-functional requirements) — সিস্টেম কীভাবে আচরণ করে। "পেজটি ২০০ মিলি-সেকেন্ডের মধ্যে লোড হবে।" "সিস্টেমটি ১ কোটি ইউজার সামলাতে পারবে।" "ডাটা কখনোই হারাবে না।" এগুলোকে ফাইন প্রিন্ট বা শর্তাবলীর মতো ভাবতে পারেন।

এখানে একটা মজার ব্যাপার হলো: নন-ফাংশনাল রিকোয়ারমেন্টেই ইন্টারভিউগুলো জমজমাট হয়। যে কেউ বলতে পারে "ইউজাররা টুইট পোস্ট করতে পারবে।" আসল চ্যালেঞ্জ হলো সেটাকে ৫০ কোটি ইউজারের জন্য ৯৯.৯৯% আপটাইম (Uptime)-সহ কাজ করানো।

সাধারণ নন-ফাংশনাল রিকোয়ারমেন্টগুলোর মধ্যে রয়েছে:

স্কেলেবিলিটি (Scalability) — এটা কি ইউজার বাড়ার সাথে সাথে বড় হতে পারবে?
অ্যাভেইলেবিলিটি (Availability) — এটা কি সবসময় চালু থাকে?
ল্যাটেন্সি (Latency) — এটা কি ফাস্ট?
কনসিস্টেন্সি (Consistency) — সবাই কি একই ডাটা দেখতে পায়?
ডিউরেবিলিটি (Durability) — সার্ভার পুড়ে গেলেও কি ডাটা ইকোসিস্টেমে সুরক্ষিত থাকে?

Note: ইন্টারভিউ টিপস: সিস্টেম ডিজাইন ইন্টারভিউর প্রথম ৩-৫ মিনিট সবসময় রিকোয়ারমেন্টগুলো ক্লিয়ার করার জন্য ব্যয় করুন। জিজ্ঞেস করুন "কত ইউজার?" "কোনটা বেশি গুরুত্বপূর্ণ — স্পিড নাকি কনসিস্টেন্সি?" "আমাদের কি রিয়েল-টাইম আপডেট দরকার?" এটা আপনার পরিপক্কতা দেখায় এবং আপনাকে ভুল ডিজাইনের পথে যাওয়া থেকে বাঁচায়।

ডিজাইন প্রসেস (The Design Process)

দুর্দান্ত সিস্টেম ডিজাইন একটা ফিক্সড উপায় মেনে চলে। এটাকে লেগো (LEGO) দিয়ে কিছু বানানোর মতো ভাবতে পারেন — আপনি ধাপগুলো অনুসরণ করবেন, কিন্তু তারপরও ক্রিয়েটিভিটির সুযোগ থাকবে।

ধাপ ১: সমস্যা বোঝা। আমরা কী বানাচ্ছি? এটা কারা ব্যবহার করবে? মূল ফিচারগুলো কী কী?

ধাপ ২: স্কেল অনুমান করা (Estimate the scale)। কত ইউজার? কত ডাটা? প্রতি সেকেন্ডে কতগুলো রিকোয়েস্ট (QPS)? (এ বিষয়ে নিচে আরও আলোচনা করা হয়েছে।)

ধাপ ৩: API সংজ্ঞায়িত করা। সিস্টেমটি কোন কোন এন্ডপয়েন্ট বা ইন্টারফেস এক্সপোজ করবে? এটা হলো আপনার সিস্টেম এবং বাইরের জগতের মধ্যকার চুক্তি।

ধাপ ৪: হাই-লেভেল আর্কিটেকচার ডিজাইন করা। বড় বাক্সগুলো আঁকুন — ক্লায়েন্ট, সার্ভার, ডাটাবেস, ক্যাশ (Caches), লোড ব্যাল্যান্সার। ডাটা কীভাবে এগুলোর মধ্যে প্রবাহিত হবে তা দেখান।

ধাপ ৫: কম্পোনেন্টগুলোতে ডিপ-ডাইভ করা। সবচেয়ে আকর্ষণীয় বা ট্রিকি অংশটি বেছে নিন এবং জুম ইন করুন। ডাটাবেস স্কিমা দেখতে কেমন হবে? আপনি কোন ক্যাশিং স্ট্র্যাটেজি ব্যবহার করবেন?

ধাপ ৬: বটলনেক (Bottlenecks) সমাধান করা। ট্রাফিক হুট করে বেড়ে গেলে প্রথমে কী ফেইল করবে? সিঙ্গেল পয়েন্ট অফ ফেইলিউর (Single points of failure) কোথায়? আপনি সেগুলো কীভাবে সামলাবেন?

▸ চার ধাপের ডিজাইন প্রসেস

ব্যাক-অফ-দ্য-এনভেলপ এস্টিমেশন (Back-of-the-Envelope Estimation)

সিস্টেম ডিজাইনে বড় বড় সংখ্যা নিয়ে কাজ করতে হয়। আপনাকে প্রায়ই এমন কিছু অনুমান করতে হবে যেমন "ইউটিউবের প্রতিদিন কত স্টোরেজ লাগে?" একে বলা হয় ব্যাক-অফ-দ্য-এনভেলপ এস্টিমেশন — আপনার ডিজাইন সিদ্ধান্তকে গাইড করার জন্য দ্রুত, রাফ অংক।

যে সংখ্যাগুলো নিয়ে আপনি কাজ করবেন:

DAU (Daily Active Users) — প্রতিদিন কত মানুষ অ্যাপটি ব্যবহার করে।
QPS (Queries Per Second) — প্রতি সেকেন্ডে সার্ভারে কতগুলো রিকোয়েস্ট আসে। যদি ১ কোটি ইউজার প্রত্যেকে দিনে ১০টি রিকোয়েস্ট করে: ১ কোটি × ১০ / ৮৬৪০০ ≈ ১,১৫৭ QPS।
স্টোরেজ (Storage) — আপনার কতটুকু ডিস্ক স্পেস দরকার। যদি ১ কোটি DAU-এর প্রত্যেকে প্রতিদিন একটি ২ মেগাবাইটের ছবি আপলোড করে: ১ কোটি × ২MB = ২০TB/দিন।
ব্যান্ডউইথ (Bandwidth) — কী পরিমাণ ডাটা ইন/আউট হয়। ২০TB/দিন ÷ ৮৬৪০০ ≈ ২৩১ MB/s।

কিছু দরকারী সংখ্যা যা মনে রাখা ভালো:

১ দিন = ৮৬,৪০০ সেকেন্ড (রাফ ক্যালকুলেশনের জন্য ~১ লক্ষ ধরতে পারেন)
প্রতিদিন ১০ লক্ষ রিকোয়েস্ট ≈ ~১২ QPS
১ char = ১ বাইট, ১ int = ৪ বাইট, ১ long/timestamp = ৮ বাইট
সাধারণ টুইট-সাইজের টেক্সট = ~৩০০ বাইট
সাধারণ ছবি = ২০০KB–২MB
সাধারণ ভিডিও (১ মিনিট) = ৫০–১০০MB

কুইক এস্টিমেশন হেল্পার (Quick Estimation Helper)

def estimate_qps(dau: int, requests_per_user: int) -> float:
    """Estimate QPS from daily active users."""
    seconds_per_day = 86_400
    qps = (dau * requests_per_user) / seconds_per_day
    peak_qps = qps * 3  # Peak is typically 2-5x the average
    return {"avg_qps": round(qps, 1), "peak_qps": round(peak_qps, 1)}

def estimate_storage(dau: int, data_per_user_bytes: int, years: int) -> str:
    """Estimate total storage needed over time."""
    daily = dau * data_per_user_bytes
    total = daily * 365 * years
    units = ["B", "KB", "MB", "GB", "TB", "PB"]
    idx = 0
    val = float(total)
    while val >= 1024 and idx < len(units) - 1:
        val /= 1024
        idx += 1
    return f"{val:.1f} {units[idx]}"

# Example: A Twitter-like app
print(estimate_qps(dau=300_000_000, requests_per_user=20))
# {'avg_qps': 69444.4, 'peak_qps': 208333.3}

print(estimate_storage(
    dau=300_000_000,
    data_per_user_bytes=300,   # ~300 bytes per tweet
    years=5
))
# 146.9 TB

Output

{'avg_qps': 69444.4, 'peak_qps': 208333.3}
146.9 TB

Note: এস্টিমেশনকে অনেকটা দূরপাল্লার ভ্রমণের প্ল্যান করার মতো ভাবতে পারেন। আপনার ঠিক কত দূরত্বে যেতে হবে তা নিখুঁতভাবে জানার দরকার নেই — শুধু জানতে হবে জার্নিটা কি ২ ঘণ্টার নাকি ২০ ঘণ্টার। পার্থক্যটার ওপর নির্ভর করবে আপনি সাথে শুধু পানি ও হালকা বিস্কুট নেবেন নাকি রাতে থাকার জন্য হোটেল বুক করবেন। একই ধারণা: আপনার এস্টিমেশন একদম পারফেক্ট হতে হবে না, শুধু ডিজাইন সিদ্ধান্তকে গাইড করার জন্য কাছাকাছি কিছু হলেই চলবে।

▸ আলাদা করুন — কাজ ভাগ করে দিন

▸ ক্যাশ, CDN এবং কিউ (queue)-এর সাহায্যে রেজিলিয়েন্স যোগ করুন

সাধারণ বিল্ডিং ব্লক (Common Building Blocks)

প্রায় সব সিস্টেম ডিজাইনেই লেগোর মতো একই ধরণের পিস ব্যবহার করা হয়। এগুলো শেখা অনেকটা অ-আ-ক-খ শেখার মতো — একবার জানলে আপনি যেকোনো কিছু বানান করতে পারবেন।

লোড ব্যাল্যান্সার (Load Balancer) — একাধিক সার্ভারের মধ্যে ট্রাফিক ডিস্ট্রিবিউট করে, যাতে কোনো একক সার্ভারের ওপর চাপ না পড়ে।
ক্যাশ (Cache) — একটা ফার্স্ট টেম্পোরারি স্টোরেজ (RAM-এর মতো) যা আপনাকে বারবার ধীরগতির ডাটাবেসে যাওয়া থেকে বাঁচায়।
ডাটাবেস (Database) — যেখানে আপনার ডাটা স্থায়ীভাবে থাকে। স্ট্রাকচারড ডাটার জন্য SQL, ফ্লেক্সিবল ডাটার জন্য NoSQL।
মেসেজ কিউ (Message Queue) — এমন একটি লাইন যেখানে টাস্কগুলো প্রসেস হওয়ার জন্য অপেক্ষা করে, ফলে ট্রাফিক স্পাইক-এর সময় আপনার সিস্টেম ক্র্যাশ করে মিলিটারি না।
CDN (Content Delivery Network) — পৃথিবী জুড়ে ছড়িয়ে থাকা সার্ভার, যা ইউজারদের কাছাকাছি জায়গা থেকে স্ট্যাটিক ফাইল (ছবি, ভিডিও) সার্ভ করে।
API গেটওয়ে (Gateway) — আপনার সিস্টেমের সামনের দরজা যা অথেন্টিকেশন, রেট লিমিটিং এবং রাউটিং হ্যান্ডেল করে।

পরবর্তী লেসনগুলোতে, আমরা এগুলোর প্রত্যেকটির বিস্তারিত জানবো। শেষ পর্যন্ত আপনি লাখ লাখ ইউজার সামলানোর সিস্টেম ডিজাইন করার জন্য এগুলোকে একজন প্রো-এর মতো একত্রিত করতে পারবেন।