Latency Budget ও Tail Latency

সমস্যাটা কী?

ধরো তুমি একটা ট্রেডিং সিস্টেম বানাচ্ছো যেখানে অর্ডার আসা থেকে ম্যাচিং ইঞ্জিনে পৌঁছানো পর্যন্ত সময় হতে হবে ১০০ মাইক্রোসেকেন্ডের কম। অথবা একটা e-commerce চেকআউট, যেখানে পেজ লোড হতে হবে ২০০ মিলিসেকেন্ডের মধ্যে। প্রশ্ন হলো — এই সময়টা কোথায় কোথায় খরচ হয়? কোন কম্পোনেন্ট কতটুকু সময় নিতে পারে?

বেশিরভাগ ইঞ্জিনিয়ার latency নিয়ে কথা বলার সময় "গড়" (average) নিয়ে ভাবে। "আমাদের API-র average response time ৫০ms" — শুনতে ভালো। কিন্তু এটাই সবচেয়ে বিপজ্জনক ভুল। গড় তোমাকে মিথ্যা আত্মবিশ্বাস দেয়, কারণ এটি সেই খারাপ অভিজ্ঞতাগুলো লুকিয়ে ফেলে যেগুলো আসলে ব্যবহারকারী টের পায়।

এই লেসনে আমরা দুটো জিনিস বুঝব: কীভাবে একটি latency budget তৈরি করতে হয়, আর কেন tail latency (p99, p999) ই হলো আসল যুদ্ধক্ষেত্র।

মূল ধারণা

Latency Budget হলো একটি অনুরোধের end-to-end সর্বোচ্চ অনুমোদিত সময়, যা সিস্টেমের প্রতিটি পর্যায়ের (network, serialization, DB query, business logic) মধ্যে আগেভাগে ভাগ করে বরাদ্দ করা হয়।

ভাবো এটা একটা পরিবারের মাসিক বাজেটের মতো। মোট আয় ৫০,০০০ টাকা — এর মধ্যে বাড়িভাড়া ২০,০০০, খাবার ১৫,০০০, যাতায়াত ৫,০০০... এভাবে ভাগ করা। যদি কোনো খাত বরাদ্দের বেশি খরচ করে, পুরো বাজেট ফেল করে। Latency budget ঠিক একইভাবে কাজ করে — প্রতিটি hop-কে একটা সময় "বরাদ্দ" দেওয়া হয়।

আর Tail Latency হলো distribution-এর শেষ প্রান্তের ধীর অনুরোধগুলো। যদি ১০০০টি অনুরোধের মধ্যে ৯৯০টি দ্রুত হয় কিন্তু ১০টি ভয়াবহ ধীর হয়, সেই ১০টিই p99 latency নির্ধারণ করে — এবং প্রায়ই সবচেয়ে গুরুত্বপূর্ণ গ্রাহকরাই সেই ধীর অভিজ্ঞতা পান।

কীভাবে কাজ করে

Percentile কী এবং কেন

Percentile মানে — তোমার সব অনুরোধকে latency অনুযায়ী সাজালে কোন মান পর্যন্ত কত শতাংশ পড়ে।

Metric	অর্থ	কে অনুভব করে
p50 (median)	অর্ধেক অনুরোধ এর চেয়ে দ্রুত	"সাধারণ" ব্যবহারকারী
p95	৯৫% অনুরোধ এর চেয়ে দ্রুত	মাঝে মাঝে slow user
p99	৯৯% দ্রুত, ১% ধীর	প্রতি ১০০ অনুরোধে ১ জন
p999	৯৯.৯% দ্রুত	heavy user, যিনি অনেক request করেন

মজার ব্যাপার — যে ব্যবহারকারী একটা সেশনে ১০০টি API কল করেন, তিনি প্রায় নিশ্চিতভাবেই অন্তত একবার p99 latency দেখবেন। তাই p99 মানে "মাত্র ১% সমস্যা" নয়; এটি তোমার সবচেয়ে active গ্রাহকদের নিয়মিত অভিজ্ঞতা।

Fan-out কেন tail-কে বিস্ফোরিত করে

এটাই সবচেয়ে গুরুত্বপূর্ণ গণিত। ধরো একটি request ১০০টি ব্যাকএন্ড সার্ভিসে যায় (যেমন search aggregation), এবং সবগুলোর উত্তর লাগে। প্রতিটির p99 = ১০ms মানে প্রতিটির ১% সম্ভাবনা ১০ms-এর বেশি নেওয়ার।

একটি call দ্রুত হওয়ার সম্ভাবনা = 0.99
১০০টি call-ই দ্রুত হওয়ার সম্ভাবনা = 0.99^100 ≈ 0.366
অন্তত একটি slow হওয়ার সম্ভাবনা = 1 - 0.366 ≈ 0.634 (৬৩%)

অর্থাৎ, প্রতিটি ব্যাকএন্ডের p99 মাত্র ১০ms হলেও, overall request-এর ৬৩% ক্ষেত্রে অন্তত একটা slow call পড়বে। তাই বড় fan-out সিস্টেমে individual p99 ভালো করা যথেষ্ট নয় — tail কমাতেই হবে।

মিলিসেকেন্ড কোথায় হারায়

নিচের টেবিলটা মুখস্থ রাখার মতো (ক্রমগুলো আনুমানিক, hardware ভেদে পরিবর্তিত হয়):

অপারেশন	আনুমানিক সময়
L1 cache reference	১ ns
Main memory reference	১০০ ns
SSD random read	১৬,০০০ ns (১৬ µs)
Same datacenter round trip	৫০০,০০০ ns (০.৫ ms)
Disk (HDD) seek	১০,০০০,০০০ ns (১০ ms)
Dhaka → US round trip	প্রায় ২৫০ ms

এখান থেকে স্পষ্ট — memory access আর disk/network access-এর মধ্যে পার্থক্য হাজার থেকে লক্ষ গুণ। তাই একটা অপ্রয়োজনীয় disk read বা cross-region call পুরো budget খেয়ে ফেলতে পারে। এর সাথে যোগ হয় GC pause (garbage collection স্টপ-দ্য-ওয়ার্ল্ড করে দিতে পারে দশ-শত মিলিসেকেন্ড) এবং queueing delay (সার্ভার ব্যস্ত থাকলে অনুরোধ লাইনে দাঁড়িয়ে থাকে)।

কৌশল

Tail latency কমানোর কয়েকটি প্রমাণিত কৌশল:

• Hedged requests: একই অনুরোধ একটু দেরি করে দ্বিতীয় replica-তেও পাঠাও; যেটা আগে উত্তর দেয় সেটা নাও। Google-এর BigTable এই কৌশলে p999 নাটকীয়ভাবে কমিয়েছে।
• Timeout ও budget propagation: প্রতিটি call-এ অবশিষ্ট budget পাস করো, যাতে downstream জানে তার হাতে কত সময় আছে।
• GC tuning: trading সিস্টেমে প্রায়ই off-heap memory বা GC-free ভাষা (C++, Rust) বা ZGC/Shenandoah-এর মতো low-pause collector ব্যবহার করা হয়।
• Connection pooling ও pre-warming: cold connection বা cold cache প্রথম request-এ tail তৈরি করে।
• Load shedding: overload হলে কম-গুরুত্বপূর্ণ request বাদ দাও, যাতে বাকিদের tail না বাড়ে।

কখন ব্যবহার করবে / করবে না

Latency budget প্রতিটি গুরুত্বপূর্ণ user-facing path-এ থাকা উচিত। বিশেষত যেখানে fan-out আছে, যেখানে SLA আছে (যেমন payment, trading, ad-serving)। তবে একটা background batch job-এর জন্য microsecond-level budget বানানো অপচয় — সেখানে throughput-ই মুখ্য।

বাস্তব উদাহরণ

Amazon একটা বিখ্যাত গবেষণায় দেখিয়েছে, প্রতি ১০০ms অতিরিক্ত latency-তে তাদের বিক্রি ১% কমে। তাই তারা latency budget-কে রাজস্বের সাথে যুক্ত করে।

HFT (High-Frequency Trading) firm-গুলো — যেমন Jane Street, Jump Trading — পুরো order path-এর budget nanosecond-level-এ মাপে। তাদের কাছে network switch পার হতে কত ন্যানোসেকেন্ড লাগে সেটাও budget-এর অংশ। তারা FPGA ব্যবহার করে যাতে software stack-এর latency পুরো বাদ দেওয়া যায়।

Google-এর "The Tail at Scale" পেপার (Dean ও Barroso) এই ক্ষেত্রের ভিত্তি — তারাই hedged request আর tail-tolerance ধারণা জনপ্রিয় করেছে।