سوالات مصاحبه کش توزیع‌شده و CDN سطح میدل (50 سوال)

Question 1

«origin shield» در یک CDN چه مشکلی را حل می‌کند؟

Accepted Answer

missهای همه PoPها را از یک لایه میانی عبور می‌دهد تا origin به‌جای ده‌ها درخواست فقط یکی دریافت کند

Answer

از origin در برابر حملات SQL injection با فیلتر کردن body درخواست‌ها محافظت می‌کند

Answer

محتوای origin را به‌صورت دوره‌ای روی همه PoPها push می‌کند تا هیچ missی رخ ندهد

Answer

آدرس IP واقعی origin را با تغییر مداوم رکوردهای DNS پنهان می‌کند

Question 2

origin shield را معمولاً در کدام PoP انتخاب می‌کنند؟

Accepted Answer

PoPی که از نظر شبکه نزدیک‌ترین فاصله را به origin دارد

Answer

PoPی که بیشترین تعداد کاربران نهایی را سرو می‌کند

Answer

PoPی که دورترین فاصله را از origin دارد تا بار پخش شود

Answer

یک PoP تصادفی که در هر درخواست عوض می‌شود

Question 3

directive `stale-while-revalidate=60` چه رفتاری ایجاد می‌کند؟

Accepted Answer

تا 60 ثانیه پس از انقضا، نسخه stale فوراً سرو می‌شود و revalidation در پس‌زمینه انجام می‌شود

Answer

پاسخ دقیقاً 60 ثانیه cache شده و پس از آن کاربر باید منتظر origin بماند

Answer

cache هر 60 ثانیه یک بار بدون توجه به درخواست‌ها با origin همگام می‌شود

Answer

در صورت خطای origin، تا 60 ثانیه درخواست‌ها با `503` رد می‌شوند

Question 4

`stale-if-error` چگونه به resilience سیستم کمک می‌کند؟

Accepted Answer

اگر origin خطای `5xx` بدهد یا در دسترس نباشد، cache می‌تواند نسخه منقضی را به‌جای خطا سرو کند

Answer

هر پاسخ خطای origin را با TTL طولانی cache می‌کند تا origin دوباره درگیر نشود

Answer

درخواست را به‌طور خودکار به یک origin پشتیبان در region دیگر retry می‌کند

Answer

خطاهای origin را از لاگ‌ها حذف می‌کند تا alertها کاهش یابند

Question 5

«request coalescing» (collapsed forwarding) در یک cache چگونه کار می‌کند؟

Accepted Answer

برای چند miss همزمان روی یک کلید، فقط یک درخواست به origin می‌رود و بقیه منتظر همان پاسخ می‌مانند

Answer

چند درخواست کوچک به کلیدهای مختلف در یک batch به origin ارسال می‌شوند

Answer

پاسخ‌های چند کلید مرتبط در یک entry واحد ادغام و ذخیره می‌شوند

Answer

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

Question 6

استفاده از یک distributed lock (مثلاً `SET key NX PX`) برای جلوگیری از stampede چه ریسکی دارد که باید مدیریت شود؟

Accepted Answer

اگر holder قفل crash کند یا کند باشد، بقیه منتظر می‌مانند؛ پس قفل باید timeout داشته باشد و منتظرها fallback داشته باشند

Answer

قفل باعث می‌شود همه درخواست‌ها همزمان به دیتابیس بروند و بار دو برابر شود

Answer

قفل فقط روی cacheهای محلی کار می‌کند و در Redis قابل پیاده‌سازی نیست

Answer

قفل باعث می‌شود TTL همه کلیدهای دیگر cache صفر شود

Question 7

در cache-aside، چرا معمولاً پس از write به DB کلید cache را delete می‌کنند به‌جای اینکه مقدار جدید را set کنند؟

Accepted Answer

چون دو write همزمان ممکن است cache را به ترتیب اشتباه set کنند؛ delete ساده‌تر و idempotent است

Answer

چون set کردن مقدار در cache همیشه کندتر از delete است و latency را دو برابر می‌کند

Answer

چون cacheهای توزیع‌شده از عملیات overwrite روی کلید موجود پشتیبانی نمی‌کنند

Answer

چون delete باعث می‌شود داده در DB هم به‌طور خودکار به‌روزرسانی شود

Question 8

کدام سناریو حتی با «write به DB و سپس delete کلید» در cache-aside باعث داده stale ماندگار می‌شود؟

Accepted Answer

یک reader مقدار قدیمی را از DB خوانده، writer آپدیت و delete می‌کند، سپس reader مقدار قدیمی را در cache set می‌کند

Answer

دو reader همزمان یک کلید را از cache می‌خوانند و هر دو hit می‌گیرند

Answer

writer کلید را delete می‌کند و درخواست بعدی miss شده و مقدار جدید را از DB می‌گیرد

Answer

TTL کلید قبل از write به پایان می‌رسد و کلید به‌طور طبیعی منقضی می‌شود

Question 9

الگوی write-around برای کدام نوع workload مناسب است؟

Accepted Answer

داده‌ای که زیاد نوشته می‌شود اما به‌ندرت بلافاصله پس از نوشتن خوانده می‌شود، مثل لاگ‌ها

Answer

داده‌ای که بلافاصله پس از نوشتن بارها خوانده می‌شود، مثل پروفایل کاربر بعد از ویرایش

Answer

داده‌ای که باید با latency بسیار کم write شود حتی به قیمت از دست رفتن

Answer

داده‌ای که فقط در cache وجود دارد و نیازی به ذخیره در DB ندارد

Question 10

کدام مزیت write-behind آن را برای شمارنده‌هایی مثل تعداد view جذاب می‌کند؟

Accepted Answer

ادغام (coalesce) چندین write روی یک کلید و flush دسته‌ای آن‌ها به DB

Answer

تضمین اینکه هر increment بلافاصله و به‌صورت durable در DB ثبت شود

Answer

حذف کامل نیاز به دیتابیس برای نگه‌داری شمارنده‌ها

Answer

فراهم کردن strong consistency بین همه replicaهای دیتابیس

Question 11

hit ratio یک CDN پایین است چون URLها شامل `?utm_source=...&fbclid=...` هستند. بهترین راه‌حل چیست؟

Accepted Answer

حذف پارامترهای tracking از cache key یا whitelist کردن پارامترهای مؤثر در پاسخ

Answer

افزایش TTL همه پاسخ‌ها به یک سال تا missها کاهش یابد

Answer

غیرفعال کردن cache برای همه URLهایی که query string دارند

Answer

اضافه کردن `Vary: User-Agent` تا نسخه‌ها بهتر تفکیک شوند

Question 12

چرا `Vary: User-Agent` معمولاً ایده بدی برای cache در CDN است؟

Accepted Answer

هزاران مقدار متفاوت User-Agent وجود دارد، پس cache تکه‌تکه شده و hit ratio سقوط می‌کند

Answer

چون مرورگرها header مربوط به User-Agent را هرگز ارسال نمی‌کنند

Answer

چون `Vary` فقط با headerهای مربوط به فشرده‌سازی کار می‌کند

Answer

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

Question 13

یک صفحه که بسته به cookie سشن نام کاربر را نشان می‌دهد با `Cache-Control: public, max-age=300` سرو می‌شود. ریسک اصلی چیست؟

Accepted Answer

CDN ممکن است صفحه شخصی یک کاربر را به کاربران دیگر سرو کند و داده نشت کند

Answer

مرورگر cookie را به دلیل `public` بودن پاسخ حذف می‌کند و کاربر logout می‌شود

Answer

CDN درخواست را به دلیل وجود cookie با خطای `400` رد می‌کند

Answer

صفحه هرگز cache نمی‌شود چون cookie همیشه بخشی از cache key است

Question 14

«surrogate keys» (یا cache tags) در CDNهایی مثل Fastly چه مزیتی دارند؟

Accepted Answer

امکان purge گروهی همه پاسخ‌های مرتبط با یک موجودیت، مثل `product-42`، با یک فراخوانی

Answer

رمزنگاری cache key تا کاربران نتوانند URLهای cache شده را حدس بزنند

Answer

اختصاص یک TTL جداگانه به هر کاربر بر اساس سطح اشتراک او

Answer

جایگزین کردن نیاز به origin با ذخیره دائمی محتوا در edge

Question 15

invalidation با «versioned keys» (مثلاً `user:42:v7`) در یک distributed cache چگونه کار می‌کند؟

Accepted Answer

با هر تغییر، شماره version افزایش می‌یابد و readها کلید جدید را می‌سازند؛ کلیدهای قدیمی با TTL یا eviction حذف می‌شوند

Answer

همه versionهای یک کلید در یک لیست نگه داشته می‌شوند و reader جدیدترین را انتخاب می‌کند

Answer

cache به‌طور خودکار version را از DB می‌خواند و entryهای قدیمی را فوراً حذف می‌کند

Answer

version در TTL کدگذاری می‌شود تا کلیدهای قدیمی زودتر منقضی شوند

Question 16

یک کلید در Redis Cluster به دلیل یک رویداد وایرال 200K درخواست در ثانیه دریافت می‌کند. کدام راهکار مؤثرتر است؟

Accepted Answer

یک L1 cache کوتاه‌مدت در process اپ، یا کپی کلید با suffix تصادفی روی چند shard

Answer

اضافه کردن shardهای بیشتر به کلاستر تا بار به‌طور خودکار پخش شود

Answer

افزایش TTL آن کلید از 5 دقیقه به 1 ساعت

Answer

تغییر eviction policy کلاستر از LRU به LFU

Question 17

چرا در consistent hashing از virtual nodes (vnodes) استفاده می‌شود؟

Accepted Answer

تا هر نود فیزیکی در نقاط زیادی از حلقه باشد و توزیع بار یکنواخت‌تر شود

Answer

تا هر کلید به‌طور خودکار روی همه نودهای فیزیکی replicate شود

Answer

تا نیاز به تابع hash برای محاسبه موقعیت کلیدها حذف شود

Answer

تا نودها بتوانند بدون شبکه با یکدیگر ارتباط برقرار کنند

Question 18

Redis Cluster کلیدها را چگونه بین نودها توزیع می‌کند؟

Accepted Answer

با `CRC16(key) mod 16384` کلید را به یکی از 16384 hash slot می‌برد و slotها به نودها اختصاص دارند

Answer

با یک حلقه consistent hashing که هر نود 256 virtual node روی آن دارد

Answer

با یک سرور coordinator مرکزی که محل هر کلید را در جدولی ثبت می‌کند

Answer

با `hash(key) % N` که N تعداد نودهای primary است

Question 19

در کدام حالت Memcached انتخاب معقول‌تری از Redis به‌عنوان cache است؟

Accepted Answer

وقتی فقط key-value ساده با مقادیر blob لازم است و throughput چندنخی روی هر نود مهم است

Answer

وقتی به ساختارهای داده‌ای مثل sorted set و stream نیاز دارید

Answer

وقتی cache باید داده را روی دیسک persist کند و پس از restart بازیابی کند

Answer

وقتی replication داخلی و failover خودکار بین نودها الزامی است

Question 20

در Redis، تفاوت `allkeys-lru` و `volatile-lru` به‌عنوان `maxmemory-policy` چیست؟

Accepted Answer

`allkeys-lru` از بین همه کلیدها evict می‌کند؛ `volatile-lru` فقط از کلیدهایی که TTL دارند

Answer

`allkeys-lru` فقط کلیدهای منقضی‌شده را حذف می‌کند؛ `volatile-lru` همه کلیدها را

Answer

`volatile-lru` داده را روی دیسک می‌برد و `allkeys-lru` آن را حذف می‌کند

Answer

هر دو یکسان هستند اما `volatile-lru` فقط روی replicaها اعمال می‌شود

Question 21

مهاجم مدام برای IDهای تصادفی ناموجود درخواست می‌فرستد و همه به DB می‌رسند (cache penetration). کدام ترکیب بهترین دفاع است؟

Accepted Answer

Bloom filter از IDهای موجود جلوی cache، به همراه negative caching با TTL کوتاه

Answer

افزایش TTL همه کلیدهای موجود به چند روز تا DB کمتر درگیر شود

Answer

اضافه کردن replicaهای بیشتر به distributed cache

Answer

تغییر eviction policy از LRU به LFU

Question 22

«cache avalanche» چه تفاوتی با stampede روی یک کلید دارد؟

Accepted Answer

تعداد زیادی کلید همزمان از دست می‌روند (انقضای گروهی یا down شدن cache) و کل بار به DB منتقل می‌شود

Answer

فقط یک کلید داغ منقضی می‌شود و درخواست‌های آن به DB می‌رسند

Answer

کلیدها به‌تدریج و یکی‌یکی evict می‌شوند و hit ratio آرام کاهش می‌یابد

Answer

داده‌های stale در cache می‌مانند و هرگز invalidate نمی‌شوند

Question 23

حتی برای API پویایی که اصلاً قابل cache نیست، عبور از CDN چه مزیتی می‌تواند داشته باشد؟

Accepted Answer

TLS در edge نزدیک کاربر terminate می‌شود و اتصالات گرم و مسیر بهینه به origin استفاده می‌شود

Answer

CDN پاسخ‌های پویا را به‌صورت خودکار با TTL کوتاه برای همه کاربران cache می‌کند

Answer

CDN منطق API را در edge اجرا می‌کند و نیازی به origin نیست

Answer

CDN درخواست‌ها را batch کرده و یک‌جا به origin می‌فرستد

Question 24

چگونه می‌توان ویدیوهای پولی را از طریق CDN cache کرد بدون اینکه هر کسی بتواند لینک را به اشتراک بگذارد؟

Accepted Answer

استفاده از signed URL یا signed cookie با زمان انقضا که edge امضا را بررسی کند و امضا از cache key حذف شود

Answer

تنظیم `Cache-Control: no-store` تا هر درخواست مستقیماً به origin برود

Answer

اضافه کردن `Vary: Authorization` تا برای هر کاربر نسخه جدا cache شود

Answer

قرار دادن ویدیوها روی URLهای طولانی و تصادفی که حدس زدنشان سخت باشد

Question 25

Edge Side Includes (ESI) یا ترکیب fragment در edge چه مسئله‌ای را حل می‌کند؟

Accepted Answer

cache کردن بخش‌های مشترک صفحه با TTL طولانی و دریافت جداگانه بخش‌های شخصی یا پرتغییر

Answer

فشرده‌سازی HTML در edge قبل از ارسال به مرورگر

Answer

تبدیل خودکار تصاویر به فرمت‌های جدیدتر مثل WebP در edge

Answer

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

Question 26

در یک معماری دو سطحی (L1 داخل process و L2 در Redis)، چالش اصلی چیست؟

Accepted Answer

invalidate کردن L1 روی همه instanceها پس از تغییر داده، مثلاً با pub/sub یا TTL خیلی کوتاه

Answer

L1 همیشه از L2 کندتر است چون داده را serialize می‌کند

Answer

Redis اجازه نمی‌دهد داده‌ها در process اپ هم کپی شوند

Answer

L1 و L2 نمی‌توانند TTLهای متفاوتی داشته باشند

Question 27

چرا برخی تیم‌ها invalidation را به‌جای کد اپ بر اساس CDC (مثلاً Debezium روی binlog) انجام می‌دهند؟

Accepted Answer

چون هر تغییر commit شده در DB، حتی از سرویس‌ها یا اسکریپت‌های دیگر، invalidation را trigger می‌کند

Answer

چون CDC باعث می‌شود cache همیشه strongly consistent با DB باشد بدون هیچ تأخیری

Answer

چون CDC نیاز به TTL روی کلیدهای cache را کاملاً حذف می‌کند

Answer

چون CDC سریع‌تر از هر write مستقیم به cache عمل می‌کند

Question 28

مشکل «dual write» وقتی اپ ابتدا DB را آپدیت و سپس cache را invalidate می‌کند چیست؟

Accepted Answer

اگر process بین دو عملیات crash کند یا invalidation fail شود، cache تا TTL stale می‌ماند

Answer

DB دو بار آپدیت می‌شود و داده تکراری ایجاد می‌شود

Answer

cache و DB هر دو قفل می‌شوند و deadlock رخ می‌دهد

Answer

invalidation باعث rollback شدن تراکنش DB می‌شود

Question 29

کاربر پروفایلش را ویرایش می‌کند اما بلافاصله نسخه قدیمی را می‌بیند چون CDN آن را cache کرده. کدام راه‌حل read-your-writes را برای او تضمین می‌کند؟

Accepted Answer

برای مدت کوتاهی پس از write، درخواست‌های همان کاربر را با یک cookie یا flag از cache عبور دهیم یا نسخه جدید را از پاسخ write نمایش دهیم

Answer

TTL همه پاسخ‌های CDN را به یک ثانیه کاهش دهیم

Answer

CDN را کاملاً برای صفحات پروفایل غیرفعال کنیم

Answer

از کاربر بخواهیم چند دقیقه صبر کند و صفحه را refresh کند

Question 30

cache کردن نتیجه کامل query صفحه‌بندی‌شده (مثلاً `products?page=3&sort=price`) در مقایسه با cache کردن تک‌تک objectها چه trade-offی دارد؟

Accepted Answer

نتیجه کامل یک hit سریع می‌دهد اما invalidation سخت است چون یک تغییر روی صفحات زیادی اثر دارد

Answer

cache کردن objectها همیشه سریع‌تر است چون نیاز به یک round-trip دارد

Answer

cache کردن نتیجه کامل نیازی به invalidation ندارد چون صفحات تغییر نمی‌کنند

Answer

هیچ تفاوتی ندارند و فقط به نوع cache بستگی دارد

Question 31

در Redis با replication async، اگر primary پس از تأیید یک write ولی قبل از ارسال به replica از کار بیفتد چه می‌شود؟

Accepted Answer

replica به primary ارتقا پیدا می‌کند و آن write برای همیشه از دست می‌رود

Answer

Redis تا برگشتن primary قدیمی همه writeها را رد می‌کند

Answer

write به‌طور خودکار از AOF روی replica بازیابی می‌شود

Answer

کلاینت یک خطای تأخیری دریافت می‌کند و write را دوباره ارسال می‌کند

Question 32

10 میلیون کاربر فعال روزانه داریم و هر object پروفایل حدود 2KB است. اگر 20٪ کاربران 80٪ درخواست‌ها را تولید کنند، cache حدوداً چقدر حافظه لازم دارد؟

Accepted Answer

حدود 4GB به‌علاوه سربار ساختار داده و fragmentation، یعنی چیزی حدود 6GB

Answer

حدود 20GB چون باید همه کاربران روزانه را نگه داشت

Answer

حدود 400MB چون فقط 2٪ داده واقعاً داغ است

Answer

حدود 40GB چون هر object باید روی همه نودها کپی شود

Question 33

request hit ratio یک CDN 95٪ است اما هزینه egress از origin همچنان بالاست. محتمل‌ترین دلیل چیست؟

Accepted Answer

byte hit ratio پایین است؛ فایل‌های کوچک hit می‌شوند ولی فایل‌های بزرگ مثل ویدیو miss می‌شوند

Answer

CDN درخواست‌های hit را هم برای log به origin ارسال می‌کند

Answer

hit ratio بالا همیشه باعث افزایش هزینه egress می‌شود

Answer

CDN فایل‌ها را بدون فشرده‌سازی از origin دریافت می‌کند

Question 34

چرا برای assetهای static، versioning در URL معمولاً بهتر از purge در CDN پس از هر deploy است؟

Accepted Answer

purge به مرورگرها و proxyهای میانی نمی‌رسد و انتشارش اتمیک نیست، ولی URL جدید همه لایه‌ها را دور می‌زند

Answer

purge کردن در همه CDNها هزینه بسیار بالایی برای هر فایل دارد و ممنوع است

Answer

versioning باعث می‌شود حجم فایل‌ها کاهش یابد

Answer

CDNها فایل‌های بدون version را اصلاً cache نمی‌کنند

Question 35

کدام استراتژی Cache-Control برای HTML یک سایت محتوایی که assetهای hash شده دارد مناسب‌تر است؟

Accepted Answer

TTL کوتاه در مرورگر (یا `no-cache`)، `s-maxage` بلندتر در CDN همراه با purge هنگام انتشار

Answer

`max-age=31536000, immutable` برای HTML همانند assetها

Answer

`no-store` برای HTML تا هرگز cache نشود

Answer

بدون هیچ header و واگذاری تصمیم به heuristic مرورگر

Question 36

برای سایتی با محتوای long-tail زیاد (میلیون‌ها صفحه کم‌بازدید)، tiered caching در CDN چرا hit ratio را بهبود می‌دهد؟

Accepted Answer

درخواست‌های پراکنده از edgeهای مختلف در یک tier بالاتر تجمیع می‌شوند، پس احتمال hit آنجا بیشتر است

Answer

هر edge همه صفحات را از قبل دانلود می‌کند تا هیچ missی رخ ندهد

Answer

tier بالاتر TTL صفحات را به‌طور خودکار افزایش می‌دهد

Answer

tiered caching اندازه هر صفحه را با فشرده‌سازی کاهش می‌دهد

Question 37

در مقایسه با Anycast، هدایت کاربر به PoP با DNS (GeoDNS) چه محدودیتی دارد؟

Accepted Answer

تصمیم بر اساس IP resolver گرفته می‌شود نه کاربر، و تغییر مسیر به TTL رکورد DNS وابسته است

Answer

GeoDNS فقط با IPv6 کار می‌کند و از IPv4 پشتیبانی نمی‌کند

Answer

GeoDNS نیاز دارد هر کاربر به‌صورت دستی PoP خود را انتخاب کند

Answer

GeoDNS باعث می‌شود همه کاربران به یک PoP مرکزی هدایت شوند

Question 38

نگه‌داشتن session کاربران فقط در Redis (بدون persistence) چه trade-offی دارد؟

Accepted Answer

stateless شدن سرورهای اپ و latency کم، اما با از دست رفتن Redis همه کاربران logout می‌شوند

Answer

امنیت session بالاتر می‌رود اما سرورهای اپ باید sticky session داشته باشند

Answer

sessionها هرگز منقضی نمی‌شوند و حافظه بی‌نهایت رشد می‌کند

Answer

هیچ trade-offی ندارد چون Redis هرگز داده را از دست نمی‌دهد

Question 39

ذخیره objectهای چند مگابایتی در یک کلید Redis چه مشکلی ایجاد می‌کند؟

Accepted Answer

Redis تک‌نخی است، پس خواندن یا حذف یک value بزرگ بقیه درخواست‌ها را block می‌کند و شبکه اشباع می‌شود

Answer

Redis valueهای بزرگ‌تر از 1KB را قبول نمی‌کند

Answer

valueهای بزرگ به‌طور خودکار روی دیسک می‌روند و کند می‌شوند

Answer

کلیدهای بزرگ هرگز evict نمی‌شوند و حافظه پر می‌شود

Question 40

profiling نشان می‌دهد hitهای Redis با وجود latency شبکه 0.3ms حدود 5ms زمان می‌برند. محتمل‌ترین گلوگاه چیست؟

Accepted Answer

هزینه serialize/deserialize objectهای بزرگ (مثلاً JSON) در اپ

Answer

Redis هر hit را قبل از پاسخ روی دیسک می‌نویسد

Answer

TTL کلیدها باعث کند شدن lookup در Redis می‌شود

Answer

consistent hashing در هر درخواست کل حلقه را بازسازی می‌کند

Question 41

رندر یک صفحه به 50 کلید جداگانه از cache نیاز دارد و هر `GET` جداگانه ارسال می‌شود. بهترین بهینه‌سازی چیست؟

Accepted Answer

گرفتن کلیدها با `MGET` یا pipelining تا 50 round-trip به چند round-trip تبدیل شود

Answer

افزایش TTL همه 50 کلید تا hit ratio بالا برود

Answer

انتقال کلیدها به یک shard مجزا با CPU قوی‌تر

Answer

تبدیل هر `GET` به یک تراکنش `MULTI`/`EXEC` جداگانه

Question 42

کدام ترکیب متریک‌ها بهترین تصویر از سلامت یک لایه cache را می‌دهد؟

Accepted Answer

hit ratio، latency (p99) برای hit و miss، نرخ eviction، مصرف حافظه و بار رسیده به origin

Answer

فقط میانگین latency همه درخواست‌ها

Answer

فقط تعداد کلیدهای موجود در cache

Answer

فقط مصرف CPU سرورهای cache

Question 43

چه زمانی write-through نسبت به cache-aside با invalidation انتخاب بهتری است؟

Accepted Answer

وقتی داده بلافاصله پس از نوشتن به‌طور مکرر خوانده می‌شود و miss پس از write گران است

Answer

وقتی بیشتر داده‌های نوشته‌شده هرگز خوانده نمی‌شوند

Answer

وقتی latency write باید کمترین مقدار ممکن باشد

Answer

وقتی چند سرویس مختلف مستقیماً و بدون لایه مشترک در DB می‌نویسند

Question 44

چرا اعتبارسنجی JWT در edge (مثلاً با Cloudflare Workers) می‌تواند مفید باشد؟

Accepted Answer

درخواست‌های غیرمجاز قبل از رسیدن به origin رد می‌شوند و محتوای محافظت‌شده می‌تواند در edge cache شود

Answer

JWT دیگر نیازی به امضا ندارد چون edge قابل اعتماد است

Answer

edge می‌تواند tokenهای منقضی‌شده را به‌طور خودکار تمدید کند بدون اطلاع سرور

Answer

اعتبارسنجی در edge نیاز به HTTPS را حذف می‌کند

Question 45

چرا TTL برای negative cache entries باید معمولاً کوتاه‌تر از entryهای عادی باشد؟

Accepted Answer

چون آیتم ممکن است به‌زودی ساخته شود و کاربر نباید مدت طولانی «پیدا نشد» ببیند

Answer

چون negative entryها حافظه بیشتری از entryهای عادی مصرف می‌کنند

Answer

چون cacheها اجازه TTL طولانی برای مقادیر خالی را نمی‌دهند

Answer

چون negative entryها روی همه نودها replicate می‌شوند

Question 46

اضافه کردن 3 نود جدید به یک کلاستر Memcached با consistent hashing در ساعت اوج، چه ریسکی دارد و چگونه کاهش می‌یابد؟

Accepted Answer

بخشی از کلیدها به نودهای خالی می‌روند و موج miss ایجاد می‌شود؛ نودها را تدریجی یا با وزن کم اضافه یا warm کنید

Answer

هیچ ریسکی ندارد چون consistent hashing هیچ کلیدی را جابه‌جا نمی‌کند

Answer

همه کلیدها روی نودهای جدید کپی می‌شوند و حافظه دو برابر می‌شود

Answer

کلاستر باید کاملاً flush شود تا نودهای جدید قابل استفاده شوند

Question 47

الگوی refresh-ahead چه کاری انجام می‌دهد و برای چه داده‌ای مناسب است؟

Accepted Answer

کلیدهای پرتکرار را کمی قبل از انقضا در پس‌زمینه تازه می‌کند؛ مناسب داده داغ با بارگذاری گران

Answer

همه کلیدها را بلافاصله پس از هر write در DB دوباره بارگذاری می‌کند؛ مناسب داده کم‌خوانده

Answer

کلیدها را قبل از اولین درخواست به‌صورت تصادفی پیش‌بینی و load می‌کند؛ مناسب داده long-tail

Answer

TTL هر کلید را با هر hit دوباره از صفر شروع می‌کند؛ مناسب داده‌ای که هرگز تغییر نمی‌کند

Question 48

افزودن `immutable` به `Cache-Control: max-age=31536000` برای فایل‌های hash شده چه سودی دارد؟

Accepted Answer

مرورگر حتی هنگام reload کاربر، درخواست revalidation شرطی برای فایل نمی‌فرستد

Answer

CDN فایل را هرگز purge نمی‌کند حتی اگر درخواست purge ارسال شود

Answer

فایل به‌جای حافظه روی دیسک مرورگر ذخیره می‌شود

Answer

origin مجاز نیست محتوای آن URL را دیگر تغییر دهد

Question 49

استفاده از یک proxy مثل mcrouter یا Twemproxy جلوی Memcached به‌جای sharding در client چه مزیتی دارد؟

Accepted Answer

منطق routing، failover و تغییر توپولوژی در یک جا متمرکز می‌شود و همه زبان‌ها رفتار یکسان دارند

Answer

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

Answer

proxy به‌طور خودکار داده‌ها را روی دیسک persist می‌کند

Answer

proxy نیاز به consistent hashing را کاملاً از بین می‌برد

Question 50

origin پشت load balancer سه سرور دارد و revalidationهای CDN تقریباً هیچ‌وقت `304` نمی‌گیرند. محتمل‌ترین علت چیست؟

Accepted Answer

هر سرور `ETag` متفاوتی برای همان فایل تولید می‌کند، مثلاً بر اساس inode یا زمان build محلی

Answer

CDN header `If-None-Match` را هرگز به origin ارسال نمی‌کند

Answer

پاسخ `304` فقط برای درخواست‌های `POST` معتبر است

Answer

load balancer همه پاسخ‌های `304` را به `200` تبدیل می‌کند