🎯 ایده اصلی کتاب چیست؟

مهم‌ترین ایده کتاب این است که وقتی یک سیستم باید سریع و قابل پیش‌بینی باشد، صرفاً سریع‌تر کردن کد کافی نیست.
در یک سیستم Low-Latency، باید کل مسیر درخواست را ببینی:

Request → Network → CPU → Memory → Application → I/O → Response

گاهی مشکل اصلاً در Algorithm نیست.
ممکن است چند میکروثانیه را در کد ذخیره کنی، اما چند میلی‌ثانیه را در Network، GC، Context Switch یا I/O از دست بدهی.
بنابراین کتاب تلاش می‌کند نگاه مهندسی به Latency را از سطح «این کد کند است» به سطح «دقیقاً کجای مسیر زمان از دست می‌رود؟» ببرد.

📚 کتاب چه چیزهایی را آموزش می‌دهد؟

🌐 1️⃣ شناخت Latency
اول باید بفهمیم Latency دقیقاً چیست و چرا با Throughput یکی نیست.

🧭 2️⃣ اندازه‌گیری Latency
قبل از Optimization باید بتوانی Latency را Measure کنی؛ نه اینکه صرفاً حدس بزنی مشکل کجاست.

⚡️3️⃣ Low-Latency Programming
چگونه تصمیم‌های داخل Application می‌توانند روی زمان پاسخ تأثیر بگذارند.

🧠4️⃣ CPU و پردازش
ءCPU، Cache، Instructionها و نحوه اجرای کد می‌توانند بخشی از Latency باشند.

💾5️⃣ Memory
دسترسی به Memory همیشه یکسان نیست و رفتار Cache و Memory Access می‌تواند روی Performance تأثیر جدی بگذارد.

🗑6️⃣ Garbage Collection
در Runtimeهایی که Garbage Collection دارند، Allocation و GC می‌توانند روی Latency و مخصوصاً Tail Latency تأثیر بگذارند.

🌐7️⃣ Network Latency
گاهی Application سریع است، اما شبکه کند است.
و در سیستم‌های Distributed، یک Request ممکن است چندین Network Hop داشته باشد.

💽8️⃣ I/O
ءDisk، Network و سایر I/Oها می‌توانند بخش قابل‌توجهی از زمان اجرای یک عملیات را مصرف کنند.

📊9️⃣ Tail Latency
ءAverage Latency به‌تنهایی تصویر درستی از سیستم نمی‌دهد.
ممکن است Average بسیار خوب باشد، اما تعداد کمی از Requestها Latency بسیار بالایی داشته باشند.
برای همین Percentileهایی مثل:

p50 → p95 → p99 → p99.9

در سیستم‌های حساس اهمیت زیادی پیدا می‌کنند.

🔬🔟 Performance Measurement
ءPerformance Optimization بدون Measurement می‌تواند بهینه‌سازی قسمت اشتباه سیستم باشد.

💡 یک نکته مهم کتاب

یکی از طرز فکرهای مهم در بحث Latency این است:

Don't optimize what you haven't measured.

اگر نمی‌دانی Latency کجا ایجاد می‌شود، تغییر دادن کد الزاماً Performance را بهتر نمی‌کند.
ممکن است Developer یک Method را بهینه کند و چند درصد CPU کمتر مصرف شود، در حالی که ۹۰٪ زمان Request در یک Network Call یا Database Query سپری می‌شود.

🏗 این کتاب برای چه کسی مناسب است؟

اگر فقط با CRUD Applicationهای ساده کار می‌کنی، احتمالاً بخش زیادی از مباحث کتاب برایت بیش از نیاز روزمره است.
اما اگر روی این حوزه‌ها کار می‌کنی، کتاب بسیار ارزشمندتر می‌شود:
🚀 High-Performance Systems
🌐 Distributed Systems
📡 Networking
💾 Databases
⚡️ Low-Latency Applications
📈 High-Traffic Services
💳 Trading & Financial Systems
🎮 Real-Time Systems
🧠 Performance Engineering

📌 در یک جمله

اگر بخواهم ایده اصلی کتاب را خیلی خلاصه کنم:

ءLatency را نمی‌توان فقط با سریع‌تر نوشتن Code حل کرد؛ باید کل مسیر اجرای یک Request را ببینی، اندازه‌گیری کنی و بفهمی زمان دقیقاً کجا مصرف می‌شود.

و شاید مهم‌ترین تغییر نگرشی که این کتاب ایجاد می‌کند همین باشد:

ءPerformance یک Feature نیست؛ یک خاصیت کل سیستم است.