Back-of-the-envelope estimation: ডিজাইনের আগে হিসাব
ডিজাইনের আগে অনুমান করুন। মনে রাখার মতো সংখ্যাগুলো এবং request, storage ও bandwidth-এর একটি পূর্ণ উদাহরণ দেখুন।
Database বাছা বা server গোনার আগে সমস্যার আকার অনুমান করুন। মোটামুটি সংখ্যাই যথেষ্ট। এ থেকে বোঝা যায় একটি মেশিনেই চলবে, নাকি distributed ডিজাইন লাগবে।
মনে রাখার মতো সংখ্যা
- ১ দিন = ৮৬,৪০০ সেকেন্ড, ধরে নিন প্রায় ১,০০,০০০ (10^5) সেকেন্ড।
- দিনে ১০ লাখ request মানে প্রতি সেকেন্ডে প্রায় ১২।
- 1 KB, 1 MB, 1 GB, 1 TB: প্রতিটি আগেরটির প্রায় ১,০০০ গুণ।
- মোটামুটি latency: memory read ~১০০ ns, SSD read ~১০০ microsecond, data centre-এর ভেতরে round trip ~০.৫ ms, মহাদেশ পার ~১৫০ ms।
- একটি ভালো server প্রতি সেকেন্ডে হাজারো সহজ request সামলায়।
উদাহরণ: ছবি শেয়ারের অ্যাপ
ধরুন: দৈনিক ১ কোটি active user, প্রত্যেকে ৫০টি ছবি দেখে এবং দিনে ০.২টি আপলোড করে। গড় ছবি ২ MB।
প্রতি সেকেন্ডে read: ১ কোটি x ৫০ = দিনে ৫০ কোটি। ১,০০,০০০ দিয়ে ভাগ করলে প্রায় ৫,০০০ read/s। Peak সাধারণত গড়ের ২ থেকে ৩ গুণ, তাই প্রায় ১৫,০০০/s ধরুন।
প্রতি সেকেন্ডে write: ১ কোটি x ০.২ = দিনে ২০ লাখ আপলোড, প্রায় ২০ আপলোড/s।
দিনে storage: ২০ লাখ x ২ MB = দিনে ৪ TB, বছরে প্রায় ১.৫ PB। এ থেকেই বোঝা যায় ছবির জন্য database নয়, object storage ও CDN লাগবে।
বের হওয়া bandwidth: ৫,০০০ view/s x ২ MB = ১০ GB/s। এটি CDN-এর কাজ, একটি origin-এর নয়।
অভ্যাস
- ধারণাগুলো জোরে বলুন। উত্তরের চেয়ে এগুলো বেশি গুরুত্বপূর্ণ।
- কড়াভাবে round করুন। ৮৬,৪০০ হয়ে যায় ১,০০,০০০।
- Read আর write আলাদা করুন। অনুপাত ডিজাইন ঠিক করে।
- গড় নয়, peak-এর জন্য পরিকল্পনা করুন।
- একক মেলান (bit বনাম byte, দিন বনাম সেকেন্ড)।
ফল দিয়ে কী করবেন
এক মেশিন কী পারে তার সাথে তুলনা করুন। ২০ write/s নগণ্য। ছোট data-র ১৫,০০০ read/s একটি cache-এ ধরে। বছরে ১.৫ PB এক server-এ ধরে না।
মূল কথা: দুই মিনিটের হিসাব পুরো ডিজাইন গড়ে দেয়, তাই আগে করুন আর ধারণাগুলো লিখে রাখুন।
System Design সিরিজের 15 নম্বর পর্ব (মোট ১৫)। আগের পর্ব: Idempotency: retry নিরাপদ করার উপায়.
