سوالات مصاحبه مقیاس‌پذیری و عملکرد سطح سینیور (50 سوال)

Question 1

در load test، افزودن نود از ۸ به ۱۶ باعث شد throughput کل کاهش یابد. طبق Universal Scalability Law محتمل‌ترین توضیح چیست؟

Accepted Answer

هزینه coherency (هماهنگی جفت‌به‌جفت بین نودها) با مربع تعداد نودها رشد کرده و بر سود موازی‌سازی غالب شده

Answer

قانون Amdahl پیش‌بینی می‌کند throughput همیشه بعد از ۸ نود کاهش یابد

Answer

load balancer فقط می‌تواند ترافیک را بین حداکثر ۸ نود پخش کند

Answer

نودهای جدید به‌دلیل cold cache برای همیشه کندتر باقی می‌مانند

Question 2

hedged request برای کاهش tail latency چگونه به‌درستی پیاده‌سازی می‌شود؟

Accepted Answer

اگر پاسخ تا حدود p95 نرسید، درخواست دوم به replica دیگر ارسال و اولین پاسخ استفاده می‌شود

Answer

همه درخواست‌ها از ابتدا به دو replica ارسال می‌شوند و پاسخ کندتر انتخاب می‌شود

Answer

درخواست‌های کند بلافاصله لغو و با تأخیر نمایی دوباره به همان replica ارسال می‌شوند

Answer

timeout همه درخواست‌ها به p50 کاهش داده می‌شود تا درخواست کند وجود نداشته باشد

Question 3

یک صفحه برای رندر شدن ۲۰۰ درخواست backend به‌صورت موازی می‌زند. چرا تیم باید SLO backendها را روی p99.9 بگذارد نه p99؟

Accepted Answer

با p99، حدود ۸۷٪ صفحه‌ها حداقل یک پاسخ کند دارند؛ با p99.9 این عدد حدود ۱۸٪ است

Answer

چون p99.9 همیشه از p99 کمتر است و هشدار کمتری می‌دهد

Answer

چون محاسبه p99 در سیستم‌های توزیع‌شده غیرممکن است

Answer

چون p99.9 فقط درخواست‌های موفق را می‌شمارد

Question 4

ابزار load test شما در حلقه بسته کار می‌کند: هر worker فقط بعد از پاسخ درخواست قبلی، درخواست بعدی را می‌فرستد. در یک توقف ۵ ثانیه‌ای سرور، چه خطایی در percentileها رخ می‌دهد؟

Accepted Answer

coordinated omission: درخواست‌هایی که باید در آن مدت ارسال می‌شدند اصلاً ثبت نمی‌شوند و tail بسیار کمتر از واقعیت نشان داده می‌شود

Answer

همه درخواست‌های آن بازه دو بار شمرده می‌شوند و p99 بیش از حد بزرگ نشان داده می‌شود

Answer

ابزار throughput را بیشتر از واقعیت گزارش می‌دهد اما percentileها دقیق‌اند

Answer

هیچ خطایی رخ نمی‌دهد چون حلقه بسته دقیق‌ترین روش اندازه‌گیری است

Question 5

معماری سه لایه دارد (gateway → service → DB client) و هر لایه در صورت خطا تا ۳ بار کل تلاش را انجام می‌دهد. وقتی DB به‌طور کامل خطا می‌دهد، هر درخواست کاربر حداکثر چند تلاش به DB ایجاد می‌کند؟

Accepted Answer

۲۷ تلاش

Answer

۹ تلاش

Answer

۳ تلاش

Answer

۸۱ تلاش

Question 6

retry budget (مثلاً حداکثر ۱۰٪ درخواست‌ها می‌توانند retry باشند) چه مشکلی را حل می‌کند که exponential backoff به‌تنهایی حل نمی‌کند؟

Accepted Answer

بار کل retryها را در خرابی گسترده محدود می‌کند، چون backoff فقط زمان retry هر کلاینت را پخش می‌کند

Answer

تضمین می‌کند هر درخواست ناموفق در نهایت موفق شود

Answer

latency درخواست‌های موفق را به نصف کاهش می‌دهد

Answer

نیاز به idempotency در سرور را حذف می‌کند

Question 7

یک جهش کوتاه ترافیک باعث overload شد؛ جهش تمام شد اما سیستم ساعت‌ها در حالت overload ماند. این الگو چه نام دارد و ریشه معمولش چیست؟

Accepted Answer

metastable failure؛ یک حلقه بازخورد مثل retry، timeout یا cache miss بار را بالای ظرفیت نگه می‌دارد

Answer

split brain؛ دو leader همزمان درخواست‌ها را پردازش می‌کنند

Answer

memory leak؛ حافظه به‌مرور پر می‌شود و هیچ ارتباطی با جهش ندارد

Answer

clock skew؛ ساعت نودها از هم فاصله گرفته‌اند

Question 8

سرویسی با یک worker و زمان سرویس میانگین ۱۰ms را با فرض M/M/1 در نظر بگیرید. در utilization برابر ۹۰٪، میانگین زمان پاسخ کل تقریباً چقدر است؟

Accepted Answer

حدود ۱۰۰ms

Answer

حدود ۱۱ms

Answer

حدود ۱۹ms

Answer

حدود ۹۰۰ms

Question 9

دو سرویس utilization و زمان سرویس میانگین یکسانی دارند، اما زمان سرویس یکی بسیار پرنوسان است (برخی درخواست‌ها ۱۰۰ برابر کندتر). کدام گزاره درست است؟

Accepted Answer

سرویس پرنوسان صف و latency بسیار بیشتری دارد، چون انتظار با واریانس زمان سرویس رشد می‌کند

Answer

هر دو latency یکسانی دارند چون utilization و میانگین برابر است

Answer

سرویس پرنوسان latency کمتری دارد چون بیشتر درخواست‌هایش سریع‌اند

Answer

واریانس فقط روی throughput اثر دارد، نه latency

Question 10

بعد از یک incident، صف ۱۸ میلیون پیام backlog دارد. تولید ۴,۰۰۰ پیام در ثانیه و ظرفیت مصرف ۱۰,۰۰۰ پیام در ثانیه است. خالی شدن backlog چقدر طول می‌کشد؟

Accepted Answer

حدود ۵۰ دقیقه

Answer

حدود ۳۰ دقیقه

Answer

حدود ۷۵ دقیقه

Answer

حدود ۵ دقیقه

Question 11

قانون Amdahl برای کاری با ۵٪ بخش سریالی سقف ۲۰ برابر را پیش‌بینی می‌کند، اما سیستم‌های داده بزرگ با هزاران نود مفید هستند. قانون Gustafson این را چگونه توضیح می‌دهد؟

Accepted Answer

با افزایش نودها اندازه مسئله هم بزرگ می‌شود و سهم بخش سریالی از کل کار کوچک‌تر می‌شود

Answer

Gustafson ثابت می‌کند بخش سریالی با نود بیشتر خودبه‌خود موازی می‌شود

Answer

Gustafson فقط برای GPUها کاربرد دارد و در سیستم‌های توزیع‌شده معنا ندارد

Answer

Amdahl اشتباه است و speedup همیشه با تعداد نودها خطی است

Question 12

در پیک، latency API بالا رفت و CPU اپ هم بالا رفت (به‌دلیل انتظار و serialization). autoscaler تعداد podها را از ۲۰ به ۶۰ رساند و سیستم کاملاً از کار افتاد. محتمل‌ترین دلیل چیست؟

Accepted Answer

گلوگاه واقعی دیتابیس بود و podهای بیشتر اتصال و کوئری همزمان بیشتری به آن فرستادند

Answer

Kubernetes در بیش از ۵۰ pod به‌طور خودکار شبکه را throttle می‌کند

Answer

podهای جدید نسخه قدیمی‌تر کد را اجرا کردند

Answer

autoscaler باید حافظه را می‌سنجید چون CPU هیچ‌وقت معیار معتبری نیست

Question 13

۸۰ pod هر کدام pool با `maxPoolSize=25` دارند و Postgres روی `max_connections=500` است. در deploy به‌روش rolling با `maxSurge=25%` چه اتفاقی می‌افتد؟

Accepted Answer

تقاضای بالقوه تا ۲,۵۰۰ اتصال می‌رسد و podها در پیک خطای اتصال می‌گیرند؛ باید pooler یا pool کوچک‌تر داشت

Answer

Postgres به‌طور خودکار `max_connections` را بر اساس تقاضا افزایش می‌دهد

Answer

هیچ مشکلی پیش نمی‌آید چون poolها تا وقتی لازم نباشد اتصال باز نمی‌کنند

Answer

فقط podهای قدیمی خطا می‌گیرند و کاربران اثری نمی‌بینند

Question 14

p50 یک سرویس JVM حدود ۵ms است اما p99.9 حدود ۴۰۰ms، و spikeها با زمان‌های major GC همبستگی دارند. کدام راهکار مستقیماً مؤثرتر است؟

Accepted Answer

کاهش نرخ allocation و استفاده از collector کم‌مکث مثل ZGC یا G1 با هدف pause

Answer

دو برابر کردن تعداد podها بدون تغییر تنظیمات JVM

Answer

افزایش timeout کلاینت‌ها به ۱ ثانیه

Answer

فعال کردن compression روی همه پاسخ‌ها

Question 15

چرا برخی سیستم‌ها (مثلاً در Facebook) در شرایط overload صف درخواست را از FIFO به LIFO تغییر می‌دهند؟

Accepted Answer

درخواست‌های قدیمی احتمالاً کلاینتشان timeout شده؛ سرو کردن جدیدترین‌ها goodput را حفظ می‌کند

Answer

LIFO همیشه میانگین latency کمتری از FIFO دارد، حتی در بار کم

Answer

LIFO ترتیب پردازش درخواست‌های هر کاربر را تضمین می‌کند

Answer

LIFO نیاز به timeout در سمت سرور را کاملاً حذف می‌کند

Question 16

کتابخانه‌هایی مثل Netflix concurrency-limits به‌جای rate limit ثابت از سقف concurrency تطبیقی استفاده می‌کنند. ایده اصلی چیست؟

Accepted Answer

سقف درخواست‌های در جریان را با سیگنال latency (شبیه TCP Vegas) به‌صورت پویا تنظیم می‌کنند

Answer

یک عدد RPS ثابت را از load test می‌گیرند و هرگز تغییر نمی‌دهند

Answer

همه درخواست‌ها را تا کاهش CPU زیر ۵۰٪ رد می‌کنند

Answer

تعداد podها را بر اساس latency افزایش می‌دهند

Question 17

timeline با fan-out on write (denormalize کردن پست در inbox هر follower) پیاده شده. کاربری با ۵۰ میلیون follower پست می‌گذارد. بهترین رویکرد چیست؟

Accepted Answer

رویکرد hybrid: پست حساب‌های بسیار پرفالوور در زمان خواندن merge شود و بقیه fan-out on write بمانند

Answer

همان fan-out on write با workerهای بیشتر برای نوشتن ۵۰ میلیون رکورد

Answer

کل سیستم را به fan-out on read تبدیل کنیم

Answer

تعداد follower هر کاربر را به ۱ میلیون محدود کنیم

Question 18

سرویس inference روی GPU درخواست‌ها را batch می‌کند. SLO برابر p99 < ۱۵۰ms است و اجرای یک batch حدود ۶۰ms طول می‌کشد. حداکثر پنجره انتظار batching منطقی چقدر است؟

Accepted Answer

حدود ۳۰ تا ۴۰ms، تا با زمان اجرا و حاشیه شبکه و صف زیر ۱۵۰ms بماند

Answer

حدود ۱۵۰ms، چون هر چه batch بزرگ‌تر باشد بهتر است

Answer

صفر؛ batching همیشه SLO latency را نقض می‌کند

Answer

حدود ۱ ثانیه برای حداکثر بهره‌وری GPU

Question 19

میلیاردها پیام JSON کوچک (حدود ۳۰۰ بایت) بین regionها replicate می‌شوند و هزینه egress زیاد است. gzip روی هر پیام تقریباً بی‌اثر است. بهترین گزینه چیست؟

Accepted Answer

zstd با dictionary آموزش‌دیده روی نمونه پیام‌ها، یا فشرده‌سازی batchهای پیام

Answer

بالاترین سطح gzip روی هر پیام جداگانه

Answer

base64 کردن پیام‌ها قبل از ارسال

Answer

ارسال هر پیام دو بار برای اطمینان از رسیدن

Question 20

SLO برابر ۹۹.۹٪ در ۳۰ روز است و نرخ خطای فعلی ۱.۴۴٪ است. burn rate چقدر است و اگر ادامه یابد کل budget ماه چقدر دوام می‌آورد؟

Accepted Answer

burn rate برابر ۱۴.۴؛ budget حدود ۲ روز دوام می‌آورد

Answer

burn rate برابر ۱.۴۴؛ budget حدود ۲۰ روز دوام می‌آورد

Answer

burn rate برابر ۱۴۴؛ budget حدود ۵ ساعت دوام می‌آورد

Answer

burn rate برابر ۰.۱؛ budget هرگز تمام نمی‌شود

Question 21

چرا هشدارهای SLO مبتنی بر burn rate معمولاً از دو پنجره (مثلاً ۱ ساعت و ۵ دقیقه) همزمان استفاده می‌کنند؟

Accepted Answer

پنجره بلند اهمیت مصرف budget را تأیید می‌کند و پنجره کوتاه مطمئن می‌شود مشکل هنوز ادامه دارد

Answer

چون ابزارهای مانیتورینگ نمی‌توانند پنجره‌ای بیشتر از ۵ دقیقه را محاسبه کنند

Answer

تا هشدار دو بار ارسال شود و احتمال دیده شدن بیشتر شود

Answer

چون SLO باید هم برای latency و هم برای availability جدا تعریف شود

Question 22

SLI availability شما از لاگ‌های سرور اپ محاسبه می‌شود و ۹۹.۹۸٪ است، اما کاربران از قطعی شکایت دارند. محتمل‌ترین ایراد اندازه‌گیری چیست؟

Accepted Answer

درخواست‌هایی که هرگز به سرور نرسیدند (DNS، load balancer، crash) در لاگ سرور دیده نمی‌شوند

Answer

لاگ‌های سرور همیشه خطاها را دو بار ثبت می‌کنند

Answer

SLI باید فقط از CPU سرورها محاسبه شود

Answer

۹۹.۹۸٪ از نظر آماری با شکایت کاربران سازگار نیست

Question 23

سرویسی روی ۳ AZ با بار مساوی پخش شده و باید خرابی کامل یک AZ را بدون کاهش کیفیت تحمل کند. حداکثر utilization هدف در حالت عادی چقدر است؟

Accepted Answer

حدود ۶۶٪ از ظرفیت قابل قبول هر AZ

Answer

حدود ۳۳٪ از ظرفیت قابل قبول هر AZ

Answer

حدود ۹۰٪ از ظرفیت قابل قبول هر AZ

Answer

حدود ۵۰٪ از ظرفیت قابل قبول هر AZ

Question 24

روزانه ۲ میلیارد رویداد لاگ با میانگین ۵۰۰ بایت تولید می‌شود؛ compression نسبت ۵ به ۱ می‌دهد، replication سه‌گانه است و retention ۹۰ روز. فضای ذخیره‌سازی پایدار تقریباً چقدر است؟

Accepted Answer

حدود ۵۴ ترابایت

Answer

حدود ۹۰ ترابایت

Answer

حدود ۲۷۰ ترابایت

Answer

حدود ۱۸ ترابایت

Question 25

یک کلید در Redis Cluster (موجودی یک محصول در flash sale) ۴۰٪ کل ترافیک را می‌گیرد و shard آن اشباع شده. کدام ترکیب مؤثرترین است؟

Accepted Answer

cache محلی کوتاه‌مدت برای خواندن‌ها و تقسیم شمارنده نوشتن به چند زیرکلید (sharded counter)

Answer

اضافه کردن shardهای بیشتر به cluster

Answer

افزایش TTL همان کلید در Redis

Answer

انتقال کلید به یک instance Redis بزرگ‌تر با همان الگوی دسترسی

Question 26

شمارنده بازدید ویدیو با `UPDATE views = views + 1` روی هر بازدید پیاده شده و ردیف‌های ویدیوهای وایرال lock contention شدید دارند. بهترین بازطراحی چیست؟

Accepted Answer

تجمیع افزایش‌ها در حافظه یا stream و flush دوره‌ای به‌صورت یک `UPDATE` با مجموع

Answer

استفاده از تراکنش `SERIALIZABLE` برای هر افزایش

Answer

خواندن مقدار، افزایش در اپ و نوشتن مجدد بدون lock

Answer

افزودن index روی ستون `views`

Question 27

latency سرویسی زیر بار ۵ برابر می‌شود، اما CPU فقط ۳۰٪ است و flame graph معمولی (on-CPU) چیز غیرعادی نشان نمی‌دهد. قدم بعدی تحلیل چیست؟

Accepted Answer

off-CPU profiling برای دیدن زمان block شدن روی lock، I/O یا انتظار pool

Answer

ارتقای CPU چون CPU سریع‌تر همیشه latency را کم می‌کند

Answer

افزایش sampling rate همان on-CPU profiler

Answer

افزودن cache جلوی همه endpointها بدون تحلیل بیشتر

Question 28

SLO یک endpoint برابر p99 < ۳۰۰ms است و باید auth (p99 ۴۰ms)، profile (p99 ۹۰ms)، recommendations (p99 ۱۸۰ms) و pricing (p99 ۷۰ms) را صدا بزند. کدام طراحی SLO را محقق می‌کند؟

Accepted Answer

auth اول، سپس سه فراخوانی دیگر موازی، و recommendations با timeout و fallback

Answer

هر چهار فراخوانی به‌صورت ترتیبی با timeout یکسان ۳۰۰ms برای هر کدام

Answer

هر چهار فراخوانی ترتیبی؛ چون مجموع p99ها دقیقاً p99 کل را می‌دهد

Answer

حذف auth برای صرفه‌جویی ۴۰ms

Question 29

در یک زنجیره ۵ سرویسی، هر سرویس timeout مستقل ۲ ثانیه دارد. در overload، سرویس‌های پایین‌دستی کار درخواست‌هایی را ادامه می‌دهند که کاربر مدت‌ها پیش رها کرده. راه‌حل اصولی چیست؟

Accepted Answer

deadline propagation: deadline مطلق درخواست در هر hop منتقل و کار در صورت گذشتن آن رها شود

Answer

افزایش timeout همه سرویس‌ها به ۱۰ ثانیه

Answer

حذف کامل timeoutها و تکیه بر TCP keepalive

Answer

اضافه کردن retry در هر hop برای جبران timeoutها

Question 30

با افزایش بار ورودی از ظرفیت فراتر، throughput خام سرور ثابت ماند اما تعداد پاسخ‌های موفق در زمان به‌شدت کاهش یافت. این پدیده چیست؟

Accepted Answer

congestion collapse؛ goodput کم می‌شود چون سرور روی درخواست‌هایی کار می‌کند که کلاینتشان timeout شده

Answer

افزایش طبیعی latency که روی goodput اثری ندارد

Answer

نشانه کافی بودن ظرفیت، چون throughput ثابت مانده است

Answer

خطای ابزار مانیتورینگ؛ throughput و goodput همیشه برابرند

Question 31

کلید cache یک صفحه پربازدید منقضی می‌شود و ۵,۰۰۰ درخواست همزمان همه یک کوئری سنگین یکسان به دیتابیس می‌زنند. کدام تکنیک در سطح اپ مستقیماً این را حل می‌کند؟

Accepted Answer

request coalescing (singleflight): فقط یک درخواست کوئری را اجرا و بقیه منتظر همان نتیجه می‌مانند

Answer

افزایش اندازه connection pool به ۵,۰۰۰

Answer

کاهش TTL کلید تا زودتر دوباره پر شود

Answer

retry فوری درخواست‌هایی که با timeout مواجه شدند

Question 32

دیتابیسی روی SSD با fsync حدود ۱ms، با هر commit یک fsync انجام دهد، به‌ظاهر حداکثر حدود ۱,۰۰۰ تراکنش در ثانیه دارد. چگونه دیتابیس‌ها بدون کاهش durability ده‌ها هزار commit در ثانیه انجام می‌دهند؟

Accepted Answer

group commit: چند تراکنش همزمان با یک fsync مشترک روی WAL پایدار می‌شوند

Answer

غیرفعال کردن fsync و تکیه بر cache سیستم‌عامل

Answer

نوشتن هر تراکنش روی دیسک جداگانه

Answer

تأیید commit قبل از نوشتن در WAL

Question 33

کلاستر Cassandra با بار نوشتن پایدار، به‌مرور p99 خواندن بدتر و I/O دیسک اشباع شده، در حالی که QPS ثابت است. محتمل‌ترین علت چیست؟

Accepted Answer

compaction عقب افتاده و تعداد SSTableها زیاد شده؛ read و write amplification بالا رفته

Answer

memtable خیلی بزرگ است و خواندن‌ها را مستقیماً block می‌کند

Answer

replication factor به‌طور خودکار افزایش یافته

Answer

کلاینت‌ها به‌دلیل keep-alive درخواست‌ها را تکرار می‌کنند

Question 34

هر بار autoscaler نمونه‌ها را scale in می‌کند، یک spike کوچک خطای ۵۰۲ دیده می‌شود. ریشه و راه‌حل درست چیست؟

Accepted Answer

نمونه‌ها قبل از خروج از load balancer و اتمام درخواست‌های در جریان kill می‌شوند؛ باید connection draining و graceful shutdown داشت

Answer

autoscaler باید هرگز scale in نکند

Answer

load balancer باید به الگوریتم random تغییر کند

Answer

نمونه‌های باقی‌مانده باید حافظه بیشتری داشته باشند

Question 35

یک API روی serverless در ترافیک پراکنده p99 حدود ۲ ثانیه دارد، در حالی که اجرای گرم ۵۰ms است. کدام راهکار ریشه را هدف می‌گیرد؟

Accepted Answer

provisioned concurrency یا حداقل نمونه گرم، به‌علاوه کاهش زمان init (bundle کوچک‌تر، اتصال lazy)

Answer

افزایش حافظه دیتابیس برای پاسخ سریع‌تر

Answer

افزایش timeout تابع به ۳۰ ثانیه

Answer

کاهش تعداد درخواست‌ها با rate limit سخت‌گیرانه

Question 36

تیمی می‌گوید: «queue جلوی سرویس گذاشتیم، پس هر ترافیکی را تحمل می‌کنیم.» نرخ ورود پایدار ۱۲۰٪ ظرفیت مصرف است. چه اتفاقی می‌افتد؟

Accepted Answer

backlog و latency بی‌نهایت رشد می‌کنند؛ queue فقط جهش‌های موقت را جذب می‌کند، نه کمبود پایدار ظرفیت

Answer

queue به‌طور خودکار ۲۰٪ پیام‌ها را فشرده و جبران می‌کند

Answer

latency ثابت می‌ماند چون queue ترتیب را حفظ می‌کند

Answer

مشکلی پیش نمی‌آید چون پیام‌ها روی دیسک ذخیره می‌شوند

Question 37

benchmark یک سرویس جدید ۲۰,۰۰۰ RPS با p99 برابر ۸ms نشان داد، اما در production با ۵,۰۰۰ RPS اشباع شد. کدام ایراد benchmark محتمل‌تر است؟

Accepted Answer

داده و الگوی دسترسی غیرواقعی؛ مثلاً تکرار چند کلید که همه از cache پاسخ داده شدند

Answer

benchmark روی سخت‌افزار سریع‌تر اجرا شد و این همیشه ۴ برابر اختلاف می‌دهد

Answer

production از HTTP/2 استفاده می‌کند که ذاتاً ۴ برابر کندتر است

Answer

p99 در benchmark همیشه از production بزرگ‌تر است

Question 38

یک job تحلیلی روی cluster اسپارک ۵۰ نودی ۲۰ دقیقه طول می‌کشد. داده ۲۰۰GB است. چرا یک مهندس senior ممکن است پیشنهاد اجرای آن روی یک ماشین بزرگ را بدهد؟

Accepted Answer

داده در RAM یک ماشین جا می‌شود و حذف سربار شبکه، shuffle و هماهنگی ممکن است آن را سریع‌تر و ارزان‌تر کند

Answer

چون Spark روی بیش از ۱۰ نود همیشه خطا می‌دهد

Answer

چون vertical scaling همیشه از horizontal سریع‌تر است

Answer

چون ماشین بزرگ نیاز به هرگونه redundancy را حذف می‌کند

Question 39

سرویسی پس از انتقال از ماشین ۱۶ هسته‌ای به ماشین ۲ سوکتی ۹۶ هسته‌ای فقط ۲ برابر سریع‌تر شد، نه ۶ برابر. کدام عامل سخت‌افزاری محتمل است؟

Accepted Answer

اثرات NUMA: دسترسی threadها به حافظه سوکت دیگر کندتر است و cache coherency ترافیک ایجاد می‌کند

Answer

هسته‌های بیشتر همیشه سرعت هر هسته را به نصف کاهش می‌دهند

Answer

سیستم‌عامل‌ها از بیش از ۳۲ هسته پشتیبانی نمی‌کنند

Answer

حافظه RAM در ماشین‌های بزرگ‌تر فشرده ذخیره می‌شود

Question 40

در یک SaaS چندمستأجره، هر بار یک مشتری بزرگ export سنگین اجرا می‌کند، p99 همه مشتریان دیگر بد می‌شود. مناسب‌ترین راهکار معماری چیست؟

Accepted Answer

ایزوله کردن منابع: صف و worker pool جدا برای کارهای سنگین و سهمیه/fair queuing به ازای tenant

Answer

افزایش تعداد کلی نمونه‌ها بدون هیچ تفکیکی

Answer

کاهش timeout همه درخواست‌ها برای همه مشتریان

Answer

غیرفعال کردن قابلیت export برای همه

Question 41

سرویسی ۲۰,۰۰۰ نوشتن در ثانیه با میانگین ۲KB دارد و همه نوشتن‌ها به ۲ region دیگر replicate می‌شوند. ترافیک ماهانه cross-region تقریباً چقدر است؟

Accepted Answer

حدود ۲۰۰ ترابایت

Answer

حدود ۱۰۰ ترابایت

Answer

حدود ۲۰ ترابایت

Answer

حدود ۲ پتابایت

Question 42

قبل از جایگزینی یک سرویس حیاتی با بازنویسی جدید، مطمئن‌ترین روش برای اعتبارسنجی ظرفیت و صحت آن تحت بار واقعی چیست؟

Accepted Answer

shadow traffic: کپی ترافیک production به سرویس جدید بدون استفاده از پاسخ‌ها و مقایسه نتایج

Answer

اجرای unit testها با پوشش ۱۰۰٪

Answer

جابه‌جایی یک‌باره کل ترافیک در ساعت کم‌بار

Answer

load test مصنوعی با یک endpoint و یک کاربر تکراری

Question 43

سرویسی ۵,۰۰۰ RPS ورودی و ۱۰۰ms latency دارد. یک وابستگی شروع به خطای ۲۰٪ می‌کند و کلاینت‌ها هر خطا را یک بار retry می‌کنند، و latency به ۳۰۰ms می‌رسد. concurrency موردنیاز تقریباً چقدر می‌شود؟

Accepted Answer

حدود ۱,۸۰۰، از ۵۰۰ قبلی

Answer

حدود ۶۰۰، از ۵۰۰ قبلی

Answer

حدود ۱,۵۰۰، از ۵۰۰ قبلی

Answer

همان ۵۰۰، چون RPS کاربران تغییری نکرده

Question 44

سرویس موجودی انبار ۹۵٪ خواندن دارد؛ نمایش در صفحه محصول چند ثانیه staleness را تحمل می‌کند اما checkout باید مقدار دقیق ببیند. بهترین طراحی کدام است؟

Accepted Answer

cache یا replica برای صفحه محصول و خواندن/رزرو مستقیم و تراکنشی از primary در checkout

Answer

همه خواندن‌ها از cache با TTL یک ساعته

Answer

همه خواندن‌ها از primary تا هیچ staleness وجود نداشته باشد

Answer

همه خواندن‌ها از replicaها، و checkout با retry تا مقدار درست شود

Question 45

داشبورد p99 را در پنجره‌های ۱ دقیقه‌ای نشان می‌دهد و تیم برای گزارش ماهانه میانگین این p99ها را می‌گیرد. چرا این روش گمراه‌کننده است؟

Accepted Answer

دقیقه‌های کم‌ترافیک و پرترافیک وزن برابر می‌گیرند و p99 ماهانه واقعی از توزیع کل درخواست‌ها به دست نمی‌آید

Answer

پنجره ۱ دقیقه‌ای همیشه p99 را صفر نشان می‌دهد

Answer

میانگین p99ها همیشه دقیقاً برابر p50 ماهانه است

Answer

این روش درست است چون میانگین‌گیری خطای نمونه‌برداری را حذف می‌کند

Question 46

ترافیک در رویدادها تا ۱۰٪ در دقیقه رشد می‌کند و از تشخیص متریک تا آماده شدن نمونه جدید ۶ دقیقه طول می‌کشد. برای اینکه autoscaling واکنشی کافی باشد، حدوداً چه headroomی لازم است؟

Accepted Answer

حدود ۷۰ تا ۸۰٪ ظرفیت اضافه نسبت به بار فعلی

Answer

حدود ۱۰٪ ظرفیت اضافه نسبت به بار فعلی

Answer

حدود ۶٪ ظرفیت اضافه نسبت به بار فعلی

Answer

هیچ headroomی لازم نیست چون autoscaler خودکار است

Question 47

hit ratio یک cache برابر ۹۹٪ است و دیتابیس فقط برای ۱٪ ترافیک (به‌علاوه حاشیه کم) اندازه‌گذاری شده. اگر cluster کش کاملاً restart شود، چه اتفاقی می‌افتد و درس طراحی چیست؟

Accepted Answer

بار دیتابیس تا حدود ۱۰۰ برابر جهش می‌کند؛ cache جزء load-bearing است و به warm-up تدریجی یا محدودسازی بار نیاز دارد

Answer

بار دیتابیس فقط ۱٪ افزایش می‌یابد چون hit ratio تغییری نمی‌کند

Answer

کاربران فقط داده کمی قدیمی‌تر می‌بینند و اثری روی دیتابیس نیست

Answer

دیتابیس به‌طور خودکار نقش cache را بر عهده می‌گیرد بدون افت performance

Question 48

سرویس gRPC پشت یک L4 load balancer است. autoscaler podهای جدید اضافه می‌کند اما CPU podهای قدیمی بالا می‌ماند و podهای جدید تقریباً بیکارند. علت چیست؟

Accepted Answer

اتصال‌های HTTP/2 طولانی‌مدت روی podهای قدیمی می‌مانند؛ load balancing در سطح درخواست (L7 یا client-side) لازم است

Answer

podهای جدید health check را رد می‌کنند و هرگز ترافیک نمی‌گیرند

Answer

gRPC فقط روی یک pod در هر node قابل اجراست

Answer

autoscaler باید بر اساس حافظه کار کند نه CPU

Question 49

سیستمی هر شب برای همه ۲۰۰ میلیون کاربر ثبت‌نامی feed پیشنهادی پیش‌محاسبه می‌کند، اما فقط ۱۵ میلیون کاربر روزانه فعال‌اند. بهینه‌ترین تغییر کدام است؟

Accepted Answer

پیش‌محاسبه فقط برای کاربران فعال اخیر و محاسبه on-demand با cache برای کاربران بازگشتی

Answer

افزایش اندازه cluster تا پیش‌محاسبه سریع‌تر تمام شود

Answer

حذف کامل پیش‌محاسبه و محاسبه همه feedها در هر درخواست

Answer

پیش‌محاسبه هر ساعت به‌جای هر شب برای همه کاربران

Question 50

سرویسی یک thread pool مشترک ۲۰۰تایی برای فراخوانی ۵ وابستگی دارد. یکی از وابستگی‌ها کند می‌شود (latency از ۲۰ms به ۲s) و کل سرویس از کار می‌افتد. توضیح کمّی و راه‌حل چیست؟

Accepted Answer

طبق قانون Little حتی ۱۰۰ RPS به آن وابستگی ۲۰۰ thread را اشغال می‌کند؛ pool جدا یا سقف concurrency برای هر وابستگی لازم است

Answer

thread poolها در Java بیش از ۱۰۰ thread را پشتیبانی نمی‌کنند

Answer

وابستگی کند CPU سرویس را مصرف می‌کند و باید CPU را ارتقا داد

Answer

باید pool را به ۱۰,۰۰۰ thread افزایش داد تا هرگز پر نشود