سوالات مصاحبه Replication و Sharding سطح میدل (50 سوال)

Question 1

کدام روش، read-your-writes را در یک سیستم با read replica پیاده می‌کند؟

Accepted Answer

خواندن داده‌های کاربر از leader تا مدتی بعد از آخرین نوشتن او

Answer

افزایش تعداد read replicaها تا lag کمتر شود

Answer

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

Answer

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

Question 2

ساده‌ترین راه برای تضمین monotonic reads در یک cluster با چند replica چیست؟

Accepted Answer

هر کاربر همیشه از یک replica ثابت (مثلاً بر اساس hash شناسه‌اش) بخواند

Answer

هر درخواست با round-robin به replica بعدی فرستاده شود

Answer

خواندن‌ها فقط از replicaی با کمترین CPU انجام شود

Answer

replication را از async به LWW تغییر دهیم

Question 3

در یک سیستم partition‌شده، کاربری پاسخ یک سوال را قبل از خود سوال می‌بیند. کدام تضمین نقض شده است؟

Accepted Answer

consistent prefix reads

Answer

read-your-writes

Answer

durability

Answer

linearizable writes روی یک key

Question 4

تیم داده می‌خواهد گزارش‌های سنگین را روی دیتابیس production اجرا کند. بهترین گزینه معمولاً چیست؟

Accepted Answer

یک replica اختصاصی برای گزارش‌ها که از ترافیک کاربران جدا است

Answer

اجرای گزارش‌ها روی leader در ساعات اوج ترافیک

Answer

اجرای گزارش‌ها روی همان replicaهای سرویس‌دهنده به کاربران

Answer

shard کردن دیتابیس فقط برای اجرای گزارش‌ها

Question 5

در یک SaaS چند-tenant، sharding بر اساس `tenant_id` چه ریسک اصلی دارد؟

Accepted Answer

یک tenant بسیار بزرگ می‌تواند یک shard را پر یا overload کند

Answer

queryهای داخل یک tenant باید به همه shardها بروند

Answer

داده‌های یک tenant بین همه shardها پخش می‌شود

Answer

ایزوله کردن tenantها از هم غیرممکن می‌شود

Question 6

برای پخش نوشتن‌های یک key بسیار داغ، کدام تکنیک رایج است؟

Accepted Answer

اضافه کردن یک پسوند تصادفی (salt) به key تا بین چند partition پخش شود

Answer

بالا بردن replication factor همان partition

Answer

تغییر الگوریتم hash از MD5 به SHA-256

Answer

انتقال آن key به shardی با دیسک بزرگ‌تر

Question 7

هزینه اصلی salting یک key داغ چیست؟

Accepted Answer

خواندن باید همه زیرکلیدها را بخواند و نتایج را ادغام کند

Answer

نوشتن‌ها باید روی همه shardهای cluster تکرار شوند

Answer

دیگر نمی‌توان آن key را replicate کرد

Answer

حجم داده ذخیره‌شده ده برابر می‌شود

Question 8

با local secondary index (document-partitioned)، query بر اساس فیلد ایندکس‌شده (نه shard key) چگونه اجرا می‌شود؟

Accepted Answer

به همه shardها فرستاده می‌شود و نتایج ادغام می‌شوند (scatter-gather)

Answer

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

Answer

مستقیماً از روی یک index سراسری مرکزی خوانده می‌شود

Answer

تا زمان rebalancing بعدی قابل اجرا نیست

Question 9

عیب اصلی global secondary index (term-partitioned) چیست؟

Accepted Answer

یک نوشتن ممکن است چند partition را درگیر کند و index اغلب async به‌روز می‌شود

Answer

خواندن روی فیلد index شده همیشه باید به همه shardها برود

Answer

فقط روی shard keyهای عددی قابل استفاده است

Answer

نمی‌توان آن را replicate کرد

Question 10

در استراتژی «تعداد ثابت partition» (مثلاً ۱۰۰۰ partition برای ۱۰ node)، اضافه کردن node جدید چگونه انجام می‌شود؟

Accepted Answer

node جدید چند partition کامل را از nodeهای موجود می‌گیرد

Answer

همه کلیدها دوباره hash و بین nodeها پخش می‌شوند

Answer

تعداد partitionها به ۱۱۰۰ افزایش می‌یابد

Answer

node جدید فقط داده‌های جدید را دریافت می‌کند

Question 11

dynamic partitioning (مثل HBase یا MongoDB) با رشد داده چه می‌کند؟

Accepted Answer

وقتی یک partition از حد مشخصی بزرگ‌تر شود آن را به دو نیم split می‌کند

Answer

همه partitionها را هر شب از نو می‌سازد

Answer

تعداد partitionها را همیشه برابر تعداد nodeها نگه می‌دارد

Answer

داده‌های اضافه را به cold storage منتقل می‌کند

Question 12

برای داده‌های سنسور که بیشتر به‌صورت «داده‌های یک دستگاه در یک بازه زمانی» query می‌شوند، کدام کلید مناسب‌تر است؟

Accepted Answer

partition بر اساس `device_id` و مرتب‌سازی داخل partition بر اساس `timestamp`

Answer

range partition فقط بر اساس `timestamp`

Answer

hash partition بر اساس `timestamp`

Answer

partition بر اساس نوع سنسور (`sensor_type`)

Question 13

در cluster با سخت‌افزار ناهمگون، vnodes چطور کمک می‌کنند؟

Accepted Answer

به nodeهای قوی‌تر vnode بیشتری داده می‌شود تا سهم بیشتری از داده بگیرند

Answer

vnodeها همه درخواست‌ها را به قوی‌ترین node می‌فرستند

Answer

nodeهای ضعیف‌تر به‌طور خودکار از cluster حذف می‌شوند

Answer

vnodeها داده را روی nodeهای ضعیف فشرده می‌کنند

Question 14

چرا rebalancing کاملاً خودکار همراه با failure detection خودکار می‌تواند خطرناک باشد؟

Accepted Answer

node کند به اشتباه مرده فرض می‌شود و انتقال داده بار را بیشتر و خرابی را زنجیره‌ای می‌کند

Answer

rebalancing خودکار همیشه داده‌ها را پاک می‌کند

Answer

rebalancing خودکار فقط در ساعات کاری کار می‌کند

Answer

rebalancing خودکار replication را برای همیشه غیرفعال می‌کند

Question 15

کدام روش برای route کردن درخواست به shard درست، رایج است؟

Accepted Answer

یک routing tier که metadata نگاشت را از سرویسی مثل ZooKeeper می‌گیرد

Answer

ارسال درخواست به همه shardها و استفاده از اولین پاسخ

Answer

انتخاب تصادفی shard و تلاش مجدد در صورت خطا

Answer

ذخیره نگاشت shardها در cookie مرورگر کاربر

Question 16

بعد از failover در async replication، leader قدیمی با نوشتن‌هایی که replicate نشده بودند برمی‌گردد. رایج‌ترین رفتار چیست و چه خطری دارد؟

Accepted Answer

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

Answer

آن نوشتن‌ها خودکار و بدون conflict با leader جدید ادغام می‌شوند

Answer

leader قدیمی دوباره leader می‌شود و leader جدید داده‌هایش را از دست می‌دهد

Answer

cluster تا زمان بررسی دستی کاملاً read-only می‌ماند

Question 17

هنگام failover در async replication، کدام follower بهترین گزینه برای promote شدن است؟

Accepted Answer

followerی که جلوترین موقعیت را در replication log دارد

Answer

followerی که بیشترین فضای خالی دیسک را دارد

Answer

followerی که زودتر از همه راه‌اندازی شده است

Answer

followerی که کمترین تعداد اتصال کلاینت را دارد

Question 18

کدام مکانیزم برای جلوگیری از آسیب split brain بعد از failover استفاده می‌شود؟

Accepted Answer

fencing (مثل STONITH) که leader قدیمی را از نوشتن باز می‌دارد

Answer

کاهش replication factor به ۱ در هنگام failover

Answer

افزایش timeout تشخیص خرابی به چند ساعت

Answer

فعال کردن LWW روی همه جدول‌ها

Question 19

کدام سناریو مورد استفاده مناسب multi-leader replication است؟

Accepted Answer

اپ چند datacenterی یا کلاینت offline-first مثل تقویم روی گوشی

Answer

یک دیتابیس کوچک تک‌سروری با ترافیک کم

Answer

سیستم بانکی که هر تراکنش باید فوراً serializable باشد

Answer

دیتابیسی که فقط read-only است و هیچ نوشتنی ندارد

Question 20

ساده‌ترین استراتژی برای کم کردن conflict در multi-leader چیست؟

Accepted Answer

همه نوشتن‌های یک رکورد یا کاربر را همیشه به یک leader مشخص route کنیم

Answer

تعداد leaderها را تا حد ممکن افزایش دهیم

Answer

replication بین leaderها را sync کنیم ولی بدون timeout

Answer

ساعت همه سرورها را یک دقیقه جلو بکشیم

Question 21

vector clock (یا version vector) چه چیزی را تشخیص می‌دهد که timestamp ساده نمی‌تواند؟

Accepted Answer

اینکه دو نوشتن هم‌زمان (concurrent) بوده‌اند یا یکی بعد از دیگری

Answer

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

Answer

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

Answer

حجم داده‌ای که در هر نوشتن تغییر کرده

Question 22

ویژگی کلیدی CRDTها (Conflict-free Replicated Data Types) چیست؟

Accepted Answer

عملیات merge آن‌ها جابه‌جایی‌پذیر، شرکت‌پذیر و idempotent است

Answer

فقط روی یک leader قابل نوشتن هستند

Answer

برای هر نوشتن به consensus بین همه replicaها نیاز دارند

Answer

conflict را با timestamp بزرگ‌تر حل می‌کنند

Question 23

sloppy quorum همراه با hinted handoff چه کاری انجام می‌دهد؟

Accepted Answer

وقتی nodeهای اصلی در دسترس نیستند، نوشتن موقتاً روی nodeهای دیگر ذخیره و بعداً تحویل می‌شود

Answer

تعداد replicaهای لازم برای خواندن را به صفر می‌رساند

Answer

نوشتن‌ها را تا برگشت nodeهای اصلی کاملاً رد می‌کند

Answer

همه replicaها را وادار به sync replication می‌کند

Question 24

در leaderless replication، read repair و anti-entropy چه تفاوتی دارند؟

Accepted Answer

read repair هنگام خواندن replicaهای قدیمی را اصلاح می‌کند؛ anti-entropy در پس‌زمینه همه داده را مقایسه می‌کند

Answer

read repair فقط روی leader و anti-entropy فقط روی followerها اجرا می‌شود

Answer

هر دو دقیقاً یک کار را با دو نام متفاوت انجام می‌دهند

Answer

read repair داده را حذف و anti-entropy داده را فشرده می‌کند

Question 25

در leaderless با N=3، تنظیم W=3 و R=1 چه trade-offی دارد؟

Accepted Answer

خواندن سریع است ولی خرابی حتی یک node نوشتن را متوقف می‌کند

Answer

نوشتن سریع است ولی خواندن ممکن است داده قدیمی برگرداند

Answer

هم خواندن و هم نوشتن خرابی دو node را تحمل می‌کنند

Answer

شرط quorum برقرار نیست و خواندن‌ها همیشه قدیمی‌اند

Question 26

کدام روش برای اجتناب از join بین shardها رایج است؟

Accepted Answer

denormalize کردن داده یا هم‌مکان کردن داده‌های مرتبط با shard key یکسان

Answer

اجرای join با قفل کردن همه shardها به‌طور هم‌زمان

Answer

تبدیل همه join‌ها به subquery در SQL

Answer

افزایش replication factor تا join محلی شود

Question 27

با جدول‌های کوچک و کم‌تغییر مثل `countries` یا `currencies` در یک دیتابیس shard‌شده معمولاً چه می‌کنند؟

Accepted Answer

آن‌ها را به‌عنوان reference table روی همه shardها کپی می‌کنند

Answer

آن‌ها را بر اساس `id` بین shardها تقسیم می‌کنند

Answer

آن‌ها را فقط روی shard اول نگه می‌دارند

Answer

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

Question 28

چرا two-phase commit (2PC) برای تراکنش‌های بین shardها پرهزینه است؟

Accepted Answer

round-tripهای بیشتر و نگه‌داشتن lock تا تصمیم coordinator، که با خرابی آن block می‌شود

Answer

چون 2PC همیشه نیمی از تراکنش‌ها را rollback می‌کند

Answer

چون 2PC فقط روی دیتابیس‌های NoSQL کار می‌کند

Answer

چون 2PC replication را غیرفعال می‌کند

Question 29

کدام ترتیب برای resharding با کمترین downtime رایج است؟

Accepted Answer

dual-write به چیدمان قدیم و جدید، backfill داده قدیمی، تأیید، سپس انتقال خواندن‌ها

Answer

توقف کامل سرویس، کپی داده و راه‌اندازی دوباره

Answer

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

Answer

حذف shardهای قدیمی و انتظار برای پر شدن خودکار جدیدها

Question 30

در directory-based sharding، چگونه از تبدیل شدن directory به گلوگاه جلوگیری می‌شود؟

Accepted Answer

replicate کردن directory و cache کردن نگاشت در لایه اپلیکیشن

Answer

پرس‌وجو از directory برای هر ردیف در هر query

Answer

نگه‌داشتن directory روی همان shardی که بیشترین بار را دارد

Answer

حذف directory بعد از اولین rebalancing

Question 31

برای query «۱۰ محصول پرفروش» روی داده hash-shard‌شده، روش درست کدام است؟

Accepted Answer

گرفتن ۱۰ مورد برتر از هر shard و ادغام آن‌ها برای انتخاب ۱۰ مورد نهایی

Answer

گرفتن ۱۰ مورد از اولین shard که پاسخ می‌دهد

Answer

گرفتن یک مورد برتر از هر shard

Answer

گرفتن ۱۰ تقسیم بر تعداد shardها از هر shard

Question 32

یک روش قابل اعتماد برای اندازه‌گیری replication lag چیست؟

Accepted Answer

نوشتن دوره‌ای timestamp در یک heartbeat table روی leader و خواندن آن از replica

Answer

مقایسه تعداد اتصال‌های باز روی leader و replica

Answer

اندازه‌گیری مصرف CPU روی replica

Answer

شمارش تعداد جدول‌ها در هر replica

Question 33

مشکل statement-based replication نسبت به row-based چیست؟

Accepted Answer

توابع غیرقطعی مثل `NOW()` یا `RAND()` روی replicaها نتیجه متفاوت می‌دهند

Answer

حجم log آن همیشه خیلی بیشتر از row-based است

Answer

نمی‌تواند دستورهای `INSERT` را replicate کند

Answer

فقط روی replicaهای هم‌نسخه با leader کار نمی‌کند

Question 34

مزیت logical (row-based) replication log نسبت به physical WAL shipping چیست؟

Accepted Answer

از storage engine مستقل است و برای CDC یا نسخه‌های متفاوت دیتابیس قابل مصرف است

Answer

همیشه سریع‌تر از هر نوع replication دیگری اعمال می‌شود

Answer

replication lag را به‌طور کامل حذف می‌کند

Answer

نیاز به leader را از بین می‌برد

Question 35

در Cassandra با primary key `((user_id), created_at)`، نقش هر بخش چیست؟

Accepted Answer

`user_id` partition را تعیین می‌کند و `created_at` ترتیب ردیف‌ها داخل partition است

Answer

`created_at` partition را تعیین می‌کند و `user_id` ترتیب داخلی است

Answer

هر دو با هم hash می‌شوند و ترتیبی وجود ندارد

Answer

`user_id` فقط یک secondary index محلی است

Question 36

جدول `users` بر اساس `user_id` shard شده است. چطور یکتایی `email` را تضمین کنیم؟

Accepted Answer

یک جدول جداگانه که با خود `email` shard شده و به‌عنوان lookup یکتا عمل می‌کند

Answer

تعریف `UNIQUE` روی `email` در هر shard کافی است

Answer

بررسی وجود email فقط در cache اپلیکیشن

Answer

انتخاب تصادفی یک shard و بررسی email در آن

Question 37

چرا IDهای سبک Snowflake (timestamp + machine id + sequence) در سیستم‌های shard‌شده محبوب‌اند؟

Accepted Answer

بدون هماهنگی مرکزی یکتا هستند و تقریباً بر اساس زمان مرتب می‌شوند

Answer

کاملاً تصادفی‌اند و هیچ اطلاعاتی از زمان ندارند

Answer

تضمین می‌کنند همه IDها روی یک shard قرار بگیرند

Answer

همیشه از UUID نسخه ۴ کوتاه‌تر و تصادفی‌ترند

Question 38

چرا خیلی از تیم‌ها از ابتدا تعداد زیادی logical shard (مثلاً ۴۰۹۶) روی چند سرور فیزیکی تعریف می‌کنند؟

Accepted Answer

تا scale کردن بعدی فقط با جابه‌جایی logical shardها بدون تغییر نگاشت key انجام شود

Answer

چون هر سرور فیزیکی حداقل به ۱۰۰۰ shard نیاز دارد

Answer

تا replication دیگر لازم نباشد

Answer

چون query روی shardهای بیشتر همیشه سریع‌تر است

Question 39

در geo-partitioning بر اساس «home region» کاربر، کدام عملیات کند می‌ماند؟

Accepted Answer

تعاملات بین کاربرانی از regionهای مختلف یا queryهای سراسری

Answer

خواندن پروفایل خود کاربر از region خودش

Answer

نوشتن تنظیمات کاربر در region خودش

Answer

لاگین کاربر در region محلی

Question 40

کدام روش اجازه می‌دهد خواندن از replica انجام شود و در عین حال read-your-writes حفظ شود؟

Accepted Answer

کلاینت موقعیت log (مثل LSN یا GTID) آخرین نوشتنش را بفرستد و replica فقط بعد از رسیدن به آن پاسخ دهد

Answer

replica همیشه بلافاصله پاسخ دهد و کلاینت در صورت قدیمی بودن refresh کند

Answer

همه replicaها هر ثانیه ری‌استارت شوند

Answer

timestamp ساعت کلاینت به‌عنوان نسخه داده استفاده شود

Question 41

چرا سیستم‌هایی مثل etcd یا CockroachDB برای انتخاب leader از الگوریتم consensus مثل Raft استفاده می‌کنند؟

Accepted Answer

تا با رأی اکثریت در هر term حداکثر یک leader معتبر وجود داشته باشد

Answer

تا بتوانند هم‌زمان چند leader در یک term داشته باشند

Answer

تا replication را از sync به async تبدیل کنند

Answer

تا نیاز به heartbeat را حذف کنند

Question 42

cascading (chained) replication، که در آن برخی replicaها از replica دیگر تغذیه می‌شوند، چه trade-offی دارد؟

Accepted Answer

بار شبکه و CPU روی leader کم می‌شود ولی lag در replicaهای پایین‌دستی بیشتر است

Answer

lag را برای همه replicaها به صفر می‌رساند

Answer

نوشتن را روی همه replicaها مجاز می‌کند

Answer

نیاز به failover را کاملاً حذف می‌کند

Question 43

delayed replica (مثلاً با تأخیر عمدی ۱ ساعت) برای چه استفاده می‌شود؟

Accepted Answer

بازیابی سریع از خطاهای انسانی مثل `DROP TABLE` قبل از رسیدن آن به replica

Answer

کاهش latency خواندن برای کاربران دور

Answer

افزایش ظرفیت نوشتن cluster

Answer

جایگزینی leader در failover خودکار

Question 44

در یک سیستم LWW، ساعت node A دو ثانیه جلوتر است. چه اتفاقی برای نوشتن بعدی روی node B می‌افتد؟

Accepted Answer

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

Answer

همیشه برنده می‌شود چون واقعاً بعداً رخ داده

Answer

سیستم conflict را تشخیص می‌دهد و به کاربر اطلاع می‌دهد

Answer

هر دو نوشتن نگه داشته و به‌عنوان sibling برگردانده می‌شوند

Question 45

چرا در leaderless replication حذف به‌صورت tombstone ثبت می‌شود نه پاک کردن فوری داده؟

Accepted Answer

تا replicaی که حذف را ندیده، داده قدیمی را دوباره به بقیه برنگرداند

Answer

چون حذف فیزیکی داده در دیسک غیرممکن است

Answer

تا حجم دیسک همیشه ثابت بماند

Answer

چون tombstone سریع‌تر از هر نوشتن دیگری replicate می‌شود

Question 46

یک key فقط از نظر خواندن بسیار داغ است (مثل پروفایل یک سلبریتی). مؤثرترین راه‌حل چیست؟

Accepted Answer

cache کردن آن در لایه جلوتر یا پخش خواندن بین replicaهای آن shard

Answer

salting کردن key و پخش نوشتن‌ها بین چند partition

Answer

تغییر shard key کل جدول

Answer

کاهش replication factor آن shard

Question 47

اجرای schema migration روی ۲۰۰ shard معمولاً چگونه انجام می‌شود؟

Accepted Answer

تغییرات backward-compatible به‌صورت تدریجی shard به shard اعمال می‌شوند

Answer

همه shardها هم‌زمان قفل می‌شوند تا migration اتمی باشد

Answer

کد جدید قبل از migration روی همه سرورها deploy می‌شود

Answer

فقط shard اول migrate می‌شود و بقیه خودشان sync می‌شوند

Question 48

با N=5، W=3، R=3 در یک سیستم leaderless، چند خرابی node قابل تحمل است در حالی که هم خواندن و هم نوشتن quorum موفق باشند؟

Accepted Answer

۲ node

Answer

۱ node

Answer

۳ node

Answer

هیچ node

Question 49

یکی از read replicaها به‌خاطر بار زیاد ۵ دقیقه عقب افتاده است. رفتار مناسب load balancer چیست؟

Accepted Answer

آن replica را تا کاهش lag زیر یک آستانه از pool خواندن خارج کند

Answer

ترافیک بیشتری به آن بفرستد تا سریع‌تر catch up کند

Answer

آن را فوراً به leader جدید promote کند

Answer

همه replicaهای دیگر را هم عقب نگه دارد تا یکسان شوند

Question 50

در multi-leader، توپولوژی all-to-all چه مزیتی نسبت به توپولوژی حلقه‌ای (circular) دارد؟

Accepted Answer

خرابی یک node جریان replication بین بقیه را قطع نمی‌کند

Answer

تضمین می‌کند پیام‌ها همیشه به ترتیب علّی درست برسند

Answer

تعداد پیام‌های replication را کمتر می‌کند

Answer

conflictها را به‌طور کامل حذف می‌کند