سوالات مصاحبه معماری رویدادمحور و Streaming سطح سینیور (50 سوال)

Question 1

برای throughput بیشتر، relay جدول outbox را روی ۴ نمونه اجرا کرده‌اید که هر کدام batchهایی را برمی‌دارند. consumerها گزارش می‌دهند `OrderShipped` گاهی قبل از `OrderPaid` می‌رسد. بهترین اصلاح چیست؟

Accepted Answer

relay را بر اساس aggregate id شارد کنیم تا eventهای هر aggregate را فقط یک نمونه به ترتیب publish کند

Answer

تعداد نمونه‌های relay را بیشتر کنیم تا هر event سریع‌تر publish شود

Answer

`created_at` را به event اضافه کنیم و از consumerها بخواهیم خودشان مرتب کنند

Answer

relay را کاملاً حذف و event را مستقیماً در تراکنش به broker بفرستیم

Question 2

می‌خواهید با CDC یک search index جدید را از جدولی با ۵۰۰ میلیون ردیف بسازید، در حالی که نوشتن‌ها ادامه دارند. چالش کلیدی چیست و رویکرد درست کدام است؟

Accepted Answer

همگام کردن snapshot اولیه با جریان تغییرات؛ snapshot از یک log position مشخص و سپس stream از همان نقطه

Answer

CDC فقط تغییرات جدید را می‌دهد، پس ردیف‌های قدیمی هرگز قابل انتقال نیستند

Answer

باید دیتابیس را تا پایان snapshot کاملاً read-only کرد و راه دیگری وجود ندارد

Answer

کافی است همه ردیف‌ها را با `SELECT *` بخوانیم و ترتیب تغییرات اهمیتی ندارد

Question 3

در یک event store با ۵ سال داده، ساختار `AddressChanged` باید تغییر کند (تقسیم `address` به چند فیلد). رویکرد ترجیحی چیست؟

Accepted Answer

upcaster که هنگام خواندن، eventهای نسخه قدیمی را به نسخه جدید تبدیل کند

Answer

UPDATE مستقیم همه eventهای قدیمی در event store با ساختار جدید

Answer

حذف eventهای قدیمی و ساختن snapshot جدید به‌جای آن‌ها

Answer

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

Question 4

سیستم event-sourced شما append-only است اما طبق GDPR باید داده شخصی یک کاربر را «فراموش» کنید. کدام راه‌حل رایج است؟

Accepted Answer

crypto-shredding: رمز کردن PII با کلید مخصوص هر کاربر و حذف کلید

Answer

افزودن event جدید `UserForgotten` و نگه‌داشتن eventهای قدیمی بدون تغییر

Answer

کاهش retention کل event store به ۳۰ روز

Answer

مخفی کردن داده کاربر فقط در read modelها و UI

Question 5

هنگام rebuild یک projection با replay کل تاریخچه، handlerی که ایمیل خوش‌آمد می‌فرستد دوباره برای میلیون‌ها کاربر ایمیل ارسال کرد. درس طراحی چیست؟

Accepted Answer

side effectهای خارجی را از projectionها جدا کنیم و در replay غیرفعال یا dedup کنیم

Answer

replay را هرگز انجام ندهیم و projectionها را دستی اصلاح کنیم

Answer

ایمیل‌ها را sync داخل aggregate ارسال کنیم تا تکرار نشوند

Answer

قبل از replay همه eventهای مرتبط با ایمیل را از store حذف کنیم

Question 6

منطق `apply` یک aggregate را تغییر داده‌اید (مثلاً نحوه محاسبه موجودی). snapshotهای موجود چه مشکلی ایجاد می‌کنند؟

Accepted Answer

state قدیمی محاسبه‌شده با منطق قبلی را منعکس می‌کنند و باید version‌دار و بازسازی شوند

Answer

هیچ مشکلی ندارند چون snapshotها مستقل از منطق aggregate هستند

Answer

eventهای بعد از snapshot به‌طور خودکار حذف می‌شوند

Answer

snapshotها باعث می‌شوند eventهای جدید در store قابل نوشتن نباشند

Question 7

دو درخواست هم‌زمان از یک حساب برداشت می‌کنند و هر دو موجودی را کافی می‌بینند. در event store چطور جلوی overdraft گرفته می‌شود؟

Accepted Answer

append با expected version؛ اگر stream در این فاصله تغییر کرده باشد، نوشتن رد و retry می‌شود

Answer

قفل سراسری روی کل event store در طول هر تراکنش

Answer

هر دو event نوشته و بعداً با یک compensating event اصلاح می‌شوند

Answer

consumerها هنگام خواندن eventهای تکراری را حذف می‌کنند

Question 8

rebuild یک read model پرمصرف از روی eventها ۶ ساعت طول می‌کشد. چطور آن را بدون downtime تغییر می‌دهید؟

Accepted Answer

projection جدید را موازی در جدول جدا بسازیم، به head برسانیم و سپس خواندن‌ها را switch کنیم

Answer

جدول فعلی را truncate و rebuild را در ساعات کم‌ترافیک اجرا کنیم

Answer

فقط eventهای جدید را با منطق جدید اعمال کنیم و داده قدیمی را رها کنیم

Answer

read model را حذف و همه queryها را مستقیماً روی event store اجرا کنیم

Question 9

یک Kafka Streams app با `processing.guarantee=exactly_once_v2` برای هر event یک API پرداخت خارجی را صدا می‌زند. آیا پرداخت‌ها exactly-once هستند؟

Accepted Answer

خیر؛ تضمین فقط برای state و topicهای Kafka است و فراخوانی خارجی باید idempotency key داشته باشد

Answer

بله؛ تراکنش Kafka فراخوانی‌های HTTP را هم rollback می‌کند

Answer

بله، به شرطی که replication factor حداقل ۳ باشد

Answer

خیر؛ چون exactly-once در Kafka فقط برای producerها کار می‌کند نه consumerها

Question 10

Flink چگونه exactly-once را برای state داخلی و یک sink تراکنشی مثل Kafka فراهم می‌کند؟

Accepted Answer

checkpointهای توزیع‌شده با barrier و two-phase commit sink که با تکمیل checkpoint commit می‌شود

Answer

ذخیره sync هر رکورد در یک دیتابیس خارجی قبل از پردازش رکورد بعدی

Answer

dedup همه رکوردهای خروجی در consumer نهایی بر اساس hash محتوا

Answer

پردازش هر رکورد روی دو TaskManager و مقایسه نتایج

Question 11

در pipeline با Flink و sink تراکنشی Kafka، پس از یک قطعی طولانی job، بخشی از داده خروجی گم شد. محتمل‌ترین علت پیکربندی چیست؟

Accepted Answer

`transaction.timeout.ms` کمتر از زمان بین checkpoint و recovery بود و broker تراکنش را abort کرد

Answer

replication factor topic خروجی بیش از حد بالا تنظیم شده بود

Answer

consumerهای پایین‌دستی با `read_uncommitted` می‌خواندند

Answer

parallelism job بیشتر از تعداد partitionهای source بود

Question 12

یک job Flink از topicی با ۱۲ partition می‌خواند. یکی از partitionها شب‌ها هیچ داده‌ای ندارد و windowها بسته نمی‌شوند. علت و راه‌حل چیست؟

Accepted Answer

watermark کلی کمینه همه partitionهاست؛ باید partition بیکار را با idleness timeout کنار گذاشت

Answer

Flink در شب به‌طور خودکار checkpointها را متوقف می‌کند

Answer

تعداد partitionها زیاد است و باید به یک partition کاهش یابد

Answer

باید به‌جای event time از ingestion time برای همه windowها استفاده کرد

Question 13

یک تیم برای سادگی windowها را بر اساس processing time تعریف کرده و حالا برای رفع باگ، داده یک ماه را replay می‌کند. چه اتفاقی می‌افتد؟

Accepted Answer

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

Answer

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

Answer

Flink replay را رد می‌کند چون processing time قابل تکرار نیست

Answer

فقط latency بیشتر می‌شود ولی تقسیم‌بندی windowها تغییری نمی‌کند

Question 14

در session windowهای مبتنی بر event time با gap سی دقیقه، یک event دیررس بین دو session موجود از یک کاربر می‌رسد. چه رفتاری صحیح است؟

Accepted Answer

اگر فاصله‌اش با هر دو کمتر از gap باشد، دو session ادغام شده و نتیجه اصلاح‌شده emit می‌شود

Answer

event همیشه به session جدیدتر اضافه می‌شود و session قدیمی ثابت می‌ماند

Answer

event به‌عنوان یک session مستقل یک‌رکوردی در نظر گرفته می‌شود

Answer

session windowها نمی‌توانند event دیررس بپذیرند و آن را دور می‌ریزند

Question 15

می‌خواهید stream کلیک‌های تبلیغ را با stream نمایش‌ها (impressions) join کنید. مهم‌ترین تصمیم طراحی چیست؟

Accepted Answer

محدود کردن join به یک بازه زمانی (windowed/interval join) تا state محدود بماند

Answer

نگه‌داشتن همه impressionها برای همیشه در state تا هیچ joinی از دست نرود

Answer

تبدیل هر دو stream به batch روزانه و join در انتهای روز

Answer

join بر اساس processing time برای کاهش پیچیدگی

Question 16

در Kafka Streams، join یک KStream سفارش‌ها (key: `orderId`) با KTable مشتری‌ها (key: `customerId`) خطا یا نتیجه نادرست می‌دهد. علت چیست؟

Accepted Answer

join نیاز به co-partitioning دارد؛ باید stream را با `customerId` rekey و repartition کرد

Answer

KTable فقط می‌تواند با KTable دیگر join شود

Answer

join فقط در صورت فعال بودن exactly-once کار می‌کند

Answer

KStream باید ابتدا به یک topic compacted تبدیل شود

Question 17

یک حساب سلبریتی ۳۰٪ eventهای `likes` را تولید می‌کند و partition آن lag بالایی دارد. نیاز business فقط شمارش تقریبی لایک‌هاست. بهترین راه چیست؟

Accepted Answer

salt کردن key (مثلاً `postId#0..N`) و تجمیع دومرحله‌ای جزئی و نهایی

Answer

افزایش تعداد consumerها بدون تغییر partition key

Answer

انتقال همه eventهای آن حساب به یک topic با یک partition

Answer

افزایش retention آن topic تا consumer فرصت جبران پیدا کند

Question 18

یک consumer group با ۲۰۰ نمونه روی Kubernetes در هر rolling deploy چند دقیقه مصرف را کاملاً متوقف می‌کند. کدام ترکیب بهترین بهبود را می‌دهد؟

Accepted Answer

static membership با `group.instance.id` و cooperative sticky assignor

Answer

کاهش `session.timeout.ms` به چند ثانیه برای تشخیص سریع‌تر

Answer

استفاده از auto-commit با فاصله یک میلی‌ثانیه

Answer

ساختن consumer group جدید با هر deploy

Question 19

consumerی گاهی batchهایی را پردازش می‌کند که ۸ دقیقه طول می‌کشد و `max.poll.interval.ms` روی ۵ دقیقه است. چه علامتی می‌بینید؟

Accepted Answer

consumer از group اخراج، rebalance و همان batch روی consumer دیگر دوباره پردازش می‌شود

Answer

Kafka پیام‌های batch را پس از ۵ دقیقه به‌طور خودکار به DLQ می‌فرستد

Answer

broker اتصال producer را قطع می‌کند تا فشار کم شود

Answer

offsetها به‌طور خودکار جلو می‌روند و پیام‌ها گم می‌شوند

Question 20

orchestrator یک saga پس از ارسال command `ReserveInventory` و قبل از ثبت آن در state خودش crash می‌کند. طراحی صحیح چه تضمینی لازم دارد؟

Accepted Answer

state saga durable باشد، commandها از طریق outbox ارسال شوند و participantها idempotent باشند

Answer

orchestrator باید stateless باشد تا crash روی آن اثری نداشته باشد

Answer

پس از restart، همه sagaهای ناتمام بدون بررسی compensate شوند

Answer

command باید sync ارسال شود و تا پاسخ نهایی منتظر بماند

Question 21

در saga سفارش، مراحل «رزرو موجودی»، «شارژ کارت» و «ارسال ایمیل تأیید» هستند. ایمیل قابل جبران نیست. ترتیب درست مراحل از دید طراحی saga چیست؟

Accepted Answer

مراحل قابل جبران اول، سپس pivot (شارژ)، و مراحل غیرقابل جبران اما retryable در انتها

Answer

ارسال ایمیل اول تا کاربر سریع‌تر مطلع شود، سپس بقیه مراحل

Answer

ترتیب اهمیتی ندارد چون همه مراحل در نهایت compensate می‌شوند

Answer

همه مراحل به‌صورت موازی اجرا شوند تا latency کمینه شود

Question 22

در saga رزرو هتل، کاربر دیگری اتاقی را می‌بیند که saga اول رزرو کرده ولی در حال compensate شدن است و ممکن است آزاد شود. کدام countermeasure مناسب است؟

Accepted Answer

semantic lock: علامت‌گذاری رکورد با وضعیت `PENDING` و رفتار مشخص برای درخواست‌های دیگر

Answer

استفاده از تراکنش `SERIALIZABLE` که بین همه سرویس‌ها گسترده شود

Answer

حذف compensation و تبدیل saga به two-phase commit

Answer

افزایش تعداد partitionهای topic مربوط به رزرو

Question 23

در یک سیستم choreography، سرویس A با `PriceChanged` سرویس B را trigger می‌کند، B با `StockAdjusted` سرویس C را و C دوباره قیمت را در A تغییر می‌دهد. خطر اصلی چیست؟

Accepted Answer

حلقه بی‌پایان event (event storm) و coupling پنهان بین سرویس‌ها

Answer

broker به‌خاطر چرخه پیام‌ها را به‌طور خودکار حذف می‌کند

Answer

فقط latency کمی افزایش می‌یابد و مشکل جدی دیگری ندارد

Answer

eventها به‌جای pub/sub به‌صورت point-to-point تحویل می‌شوند

Question 24

topic شما retention نامحدود دارد و consumerهای جدید از ابتدا می‌خوانند. compatibility mode فعلی `BACKWARD` است. چرا ممکن است کافی نباشد؟

Accepted Answer

فقط سازگاری با نسخه قبلی بررسی می‌شود نه همه نسخه‌ها؛ `BACKWARD_TRANSITIVE` لازم است

Answer

`BACKWARD` اجازه افزودن هیچ فیلد جدیدی را نمی‌دهد

Answer

`BACKWARD` فقط برای topicهای compacted معتبر است

Answer

schema registry در topicهای با retention نامحدود غیرفعال می‌شود

Question 25

یک تغییر schema فقط `FORWARD` compatible است (مثلاً حذف یک فیلد اختیاری). ترتیب امن deploy کدام است؟

Accepted Answer

ابتدا producerها، چون consumerهای قدیمی می‌توانند داده جدید را بخوانند

Answer

ابتدا consumerها، چون producerهای قدیمی داده جدید تولید می‌کنند

Answer

همه producerها و consumerها باید دقیقاً هم‌زمان deploy شوند

Answer

ترتیب مهم نیست چون schema registry تبدیل را انجام می‌دهد

Question 26

در معماری kappa، باگی در منطق محاسبه کشف شده و باید نتایج ۹۰ روز گذشته اصلاح شوند. روش صحیح چیست؟

Accepted Answer

نسخه جدید job را از offset مربوط به ۹۰ روز قبل به یک output جدید اجرا و پس از رسیدن، consumerها را switch کنیم

Answer

job فعلی را متوقف، offset را reset و روی همان جدول خروجی بازنویسی کنیم

Answer

یک batch job جداگانه با کد متفاوت برای اصلاح داده تاریخی بنویسیم

Answer

فقط از این به بعد منطق جدید را اعمال کنیم چون stream قابل بازپردازش نیست

Question 27

در چه شرایطی هنوز ممکن است lambda architecture انتخاب معقولی نسبت به kappa باشد؟

Accepted Answer

وقتی بازپردازش کل تاریخچه با stream processor بسیار پرهزینه است و الگوریتم‌های batch خاصی لازم‌اند

Answer

وقتی تیم می‌خواهد فقط یک codebase برای همه پردازش‌ها نگه دارد

Answer

وقتی داده ورودی کم است و retention log نامحدود و ارزان است

Answer

وقتی latency پایین هیچ اهمیتی برای business ندارد

Question 28

در یک ledger که ترتیب eventهای هر حساب حیاتی است، event شماره ۱۰ حساب X به DLQ رفت ولی ۱۱ و ۱۲ پردازش شدند. طراحی بهتر چیست؟

Accepted Answer

پس از ارسال یک event به DLQ، eventهای بعدی همان key را هم park کنیم تا مشکل حل شود

Answer

DLQ را حذف کرده و کل partition را تا اصلاح دستی متوقف کنیم

Answer

eventهای DLQ را بعداً بدون توجه به ترتیب redrive کنیم

Answer

تعداد retry را نامحدود کنیم تا هیچ event به DLQ نرود

Question 29

در یک job Flink، sink به Elasticsearch کند شده است. backpressure چگونه در pipeline منتشر می‌شود و اثر نهایی روی Kafka چیست؟

Accepted Answer

بافرهای شبکه بین operatorها پر و upstream کند می‌شود تا source کمتر بخواند و lag در Kafka رشد کند

Answer

Flink داده‌های اضافی را دور می‌ریزد تا throughput ثابت بماند

Answer

source همان سرعت را حفظ می‌کند و داده در heap جمع می‌شود تا OOM رخ دهد

Answer

Kafka به‌طور خودکار producerها را کند می‌کند

Question 30

سرویس ingestion در زمان اوج، درخواست‌ها را در یک صف in-memory نامحدود قرار می‌دهد و latency به چند دقیقه می‌رسد و در نهایت OOM می‌شود. اصل طراحی نقض‌شده چیست؟

Accepted Answer

صف‌ها باید bounded باشند و در پُر شدن، backpressure یا load shedding (مثلاً `429`) اعمال شود

Answer

صف‌ها باید همیشه در حافظه باشند تا latency کمینه شود

Answer

باید به‌جای صف از فراخوانی sync مستقیم به دیتابیس استفاده کرد

Answer

اندازه heap باید به‌صورت پویا تا بی‌نهایت افزایش یابد

Question 31

پس از ۲ ساعت قطعی سرویس پرداخت، ۵ میلیون پیام در DLQ و retry topicها جمع شده است. ریسک redrive همه آن‌ها به‌یکباره چیست و رویکرد درست کدام است؟

Accepted Answer

غرق شدن دوباره سرویس تازه‌بازیابی‌شده؛ redrive با rate limit و افزایش تدریجی

Answer

هیچ ریسکی ندارد چون پیام‌ها idempotent هستند

Answer

پیام‌ها به‌خاطر retention حذف می‌شوند، پس باید سریع redrive کرد

Answer

broker اجازه redrive بیش از ۱۰۰۰ پیام را نمی‌دهد

Question 32

سرویس نوتیفیکیشن SSE را روی ۲۰ نمونه پشت load balancer اجرا می‌کنید. eventی برای کاربر X در نمونه ۳ تولید می‌شود ولی اتصال X روی نمونه ۱۷ است. راه‌حل معماری چیست؟

Accepted Answer

یک pub/sub backplane (مثل Redis یا Kafka) که event را به نمونه دارنده اتصال برساند

Answer

فعال کردن sticky session تا همه eventها به نمونه ۱۷ بروند

Answer

تبدیل SSE به short polling برای حذف اتصال‌های پایدار

Answer

اجرای فقط یک نمونه بزرگ تا همه اتصال‌ها روی آن باشند

Question 33

سرویس WebSocket شما ۵۰۰ هزار اتصال هم‌زمان دارد. در هر deploy سرورهای backend با موج reconnect از کار می‌افتند. کدام ترکیب بهترین کمک را می‌کند؟

Accepted Answer

drain تدریجی اتصال‌ها، reconnect با exponential backoff و jitter سمت کلاینت و resume از آخرین event id

Answer

قطع هم‌زمان همه اتصال‌ها تا deploy سریع‌تر تمام شود

Answer

افزایش timeout اتصال‌ها به ۲۴ ساعت

Answer

جایگزینی WebSocket با webhook برای کلاینت‌های مرورگر

Question 34

در پلتفرم ارسال webhook برای هزاران مشتری، endpoint یک مشتری ۳۰ ثانیه timeout می‌دهد و تحویل برای همه مشتریان کند شده است. علت ریشه‌ای و راه‌حل چیست؟

Accepted Answer

صف و worker مشترک؛ باید ایزوله‌سازی per-endpoint با concurrency limit و circuit breaker داشت

Answer

تعداد کم partitionها؛ باید partitionها را دو برابر کرد

Answer

نبود امضای HMAC؛ باید امضا را اضافه کرد

Answer

timeout کوتاه؛ باید timeout را به ۵ دقیقه افزایش داد

Question 35

consumer شما message idهای پردازش‌شده را با TTL بیست‌وچهار ساعته در Redis نگه می‌دارد. پس از یک replay از ۳ روز قبل، پرداخت‌های تکراری ثبت شد. درس طراحی چیست؟

Accepted Answer

پنجره dedup باید حداقل به اندازه حداکثر بازه ممکن redelivery/replay باشد یا idempotency در داده business پایدار شود

Answer

Redis برای dedup مناسب نیست چون همیشه داده را گم می‌کند

Answer

replay هرگز نباید در سیستم‌های مالی انجام شود

Answer

باید TTL را کوتاه‌تر کرد تا حافظه کمتری مصرف شود

Question 36

consumer ابتدا موجودی را در PostgreSQL آپدیت و سپس message id را در Redis ثبت می‌کند. چه پنجره خطایی وجود دارد و اصلاح صحیح چیست؟

Accepted Answer

crash بین دو نوشتن باعث اعمال دوباره می‌شود؛ message id باید در همان تراکنش PostgreSQL ثبت شود

Answer

هیچ پنجره‌ای وجود ندارد چون Redis سریع‌تر از PostgreSQL است

Answer

باید ترتیب را عوض کرد تا اول Redis و بعد PostgreSQL نوشته شود

Answer

باید offset را قبل از هر دو نوشتن commit کرد

Question 37

مدیر محصول می‌خواهد «همه eventهای سیستم به ترتیب سراسری دقیق» پردازش شوند. پاسخ معماری مناسب چیست؟

Accepted Answer

ترتیب سراسری یعنی یک partition و یک consumer و سقف throughput؛ باید مرز واقعی ترتیب (مثلاً هر حساب) را پیدا کرد

Answer

با افزایش partitionها و consumerها ترتیب سراسری حفظ و throughput هم زیاد می‌شود

Answer

با timestamp ساعت سرورها می‌توان ترتیب سراسری دقیق را در هر مقیاسی تضمین کرد

Answer

Kafka به‌طور پیش‌فرض ترتیب سراسری بین همه partitionها را تضمین می‌کند

Question 38

دو cluster Kafka در دو region را به‌صورت active-active با replication دوطرفه topicها راه‌اندازی می‌کنید. مهم‌ترین مشکلی که باید از آن جلوگیری کرد چیست؟

Accepted Answer

حلقه replication بی‌پایان؛ با topicهای پیشوند‌دار بر اساس region یا header مبدأ

Answer

تفاوت تعداد brokerها بین دو region

Answer

فشرده‌سازی متفاوت پیام‌ها در هر region

Answer

نیاز به schema registry جداگانه در هر region

Question 39

در الگوی «listen to yourself»، سرویس فقط event را publish و سپس خودش با consume کردن آن دیتابیس را آپدیت می‌کند. trade-off اصلی آن نسبت به outbox چیست؟

Accepted Answer

dual write حذف می‌شود ولی خود سرویس هم eventually consistent است و read-your-writes سخت می‌شود

Answer

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

Answer

تضمین می‌کند اعتبارسنجی invariantها قبل از publish به‌صورت اتمیک انجام شود

Answer

فقط در سیستم‌هایی کار می‌کند که از two-phase commit پشتیبانی کنند

Question 40

producer تراکنشی Kafka تراکنش‌هایی را abort می‌کند، اما یک consumer پایین‌دستی همچنان آن پیام‌ها را پردازش می‌کند. علت چیست؟

Accepted Answer

consumer با `isolation.level=read_uncommitted` (پیش‌فرض) می‌خواند و باید `read_committed` باشد

Answer

abort در Kafka پیام‌ها را فقط از partition leader حذف می‌کند نه replicaها

Answer

consumer group باید با producer هم‌نام باشد

Answer

تراکنش‌ها فقط در topicهای compacted معتبرند

Question 41

یک نمونه producer به‌خاطر GC pause طولانی مرده فرض شده و جایگزین آن شروع به کار کرده است. نمونه قدیمی دوباره بیدار می‌شود و می‌خواهد بنویسد. Kafka چطور جلوی خروجی تکراری را می‌گیرد؟

Accepted Answer

با `transactional.id` ثابت و epoch؛ نمونه جدید epoch را بالا برده و نمونه zombie fence می‌شود

Answer

broker هر producer را پس از ۳۰ ثانیه بی‌فعالیتی برای همیشه ban می‌کند

Answer

consumerها پیام‌های هر دو نمونه را دریافت و با hash محتوا dedup می‌کنند

Answer

Kafka نمی‌تواند این را تشخیص دهد و باید با قفل در ZooKeeper حل شود

Question 42

jobهای تبدیل ویدیو از ۱ ثانیه تا ۱۰ دقیقه طول می‌کشند و ترتیبی ندارند. تیم از Kafka با consumer group کلاسیک استفاده می‌کند و workerها بیکار می‌مانند در حالی که lag بالاست. مشکل چیست؟

Accepted Answer

مدل offset per-partition برای کار با زمان متغیر مناسب نیست؛ queue با ack هر پیام (یا Kafka share groups) بهتر است

Answer

باید retention topic را افزایش داد تا jobها گم نشوند

Answer

باید exactly-once را فعال کرد تا workerها سریع‌تر شوند

Answer

باید همه jobها را در یک partition قرار داد

Question 43

aggregate حساب یک مشتری تجاری پس از چند سال میلیون‌ها event دارد و حتی با snapshot، concurrency conflictها زیاد است. راه‌حل مدل‌سازی مناسب چیست؟

Accepted Answer

شکستن stream با الگوی «closing the books» (مثلاً stream دوره‌ای با event انتقال مانده) یا aggregateهای کوچک‌تر

Answer

حذف eventهای قدیمی‌تر از یک سال از stream

Answer

قفل pessimistic روی کل aggregate برای هر عملیات

Answer

ذخیره snapshot بعد از هر event برای جلوگیری از conflict

Question 44

یک Kafka Streams app با state store پنجاه‌گیگابایتی پس از هر failover حدود ۴۰ دقیقه برای restore از changelog زمان می‌برد. بهترین بهبود چیست؟

Accepted Answer

standby replicas (`num.standby.replicas`) و volume پایدار برای حفظ state محلی

Answer

غیرفعال کردن changelog topic تا restore لازم نباشد

Answer

کاهش replication factor changelog برای خواندن سریع‌تر

Answer

تبدیل state store به in-memory بدون پشتیبان

Question 45

سرویس Fulfillment هم `OrderPlaced` (partition بر اساس `orderId`) و هم `PaymentCaptured` (partition بر اساس `paymentId`) را مصرف می‌کند و گاهی پرداخت قبل از سفارش می‌رسد. طراحی مقاوم چیست؟

Accepted Answer

consumer را به‌صورت state machine بسازیم که eventها را با هر ترتیبی بپذیرد و تا کامل شدن شرایط صبر کند

Answer

پیام پرداخت را تا رسیدن سفارش مدام retry کنیم تا در نهایت به DLQ برود

Answer

هر دو event را در یک topic با یک partition قرار دهیم تا ترتیب سراسری داشته باشیم

Answer

به timestamp تولید event اعتماد کنیم و eventهای قدیمی‌تر را دور بریزیم

Question 46

سرویس‌ها نسخه محلی داده مشتری را از event `CustomerUpdated` می‌سازند (retention هفت روز). یک سرویس جدید باید همه ۱۰ میلیون مشتری را داشته باشد. بهترین طراحی چیست؟

Accepted Answer

یک topic compacted با آخرین state هر مشتری که سرویس جدید از ابتدا بخواند

Answer

سرویس جدید ۱۰ میلیون درخواست HTTP به API سرویس Customer بفرستد

Answer

retention topic فعلی را به هفت سال افزایش دهیم و از ابتدا بخوانیم

Answer

مستقیماً به دیتابیس سرویس Customer وصل شویم و جدول را کپی کنیم

Question 47

orchestrator پس از ۳۰ ثانیه پاسخی از سرویس پرداخت برای command `ChargeCard` دریافت نکرده است. اقدام صحیح چیست؟

Accepted Answer

نتیجه نامعلوم است؛ با همان idempotency key وضعیت را query یا retry کنیم، سپس تصمیم به ادامه یا compensate بگیریم

Answer

فرض کنیم پرداخت شکست خورده و بلافاصله سفارش را لغو کنیم

Answer

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

Answer

command را با یک idempotency key جدید دوباره ارسال کنیم

Question 48

برای حفظ ترتیب، eventهای `OrderCreated`، `OrderPaid` و `OrderCancelled` را با schemaهای متفاوت در یک topic می‌گذارید. با schema registry چه تنظیمی لازم است؟

Accepted Answer

subject name strategy از نوع `TopicRecordNameStrategy` (یا union schema) به‌جای پیش‌فرض topic-محور

Answer

غیرفعال کردن compatibility check برای آن topic

Answer

ساختن یک schema registry جداگانه برای هر نوع event

Answer

تبدیل همه eventها به JSON بدون schema

Question 49

یک partner بزرگ می‌خواهد روزانه ۵۰ میلیون event شما را بگیرد و پس از قطعی‌های خودش بتواند از جای قبلی ادامه دهد. چرا webhook ممکن است انتخاب ضعیفی باشد و جایگزین چیست؟

Accepted Answer

push حجیم، retry و backlog را روی شما می‌گذارد؛ یک event feed مبتنی بر pull با cursor بهتر است

Answer

webhook از HTTPS پشتیبانی نمی‌کند و برای داده حساس ناامن است

Answer

webhook فقط برای eventهای کمتر از ۱ کیلوبایت کار می‌کند

Answer

webhook نیاز دارد partner یک WebSocket دائمی با شما باز نگه دارد

Question 50

sink شما Cassandra است که تراکنش two-phase commit پشتیبانی نمی‌کند. چطور خروجی effectively-once از یک stream processor با checkpoint دارید؟

Accepted Answer

نوشتن idempotent با upsert بر اساس key قطعی تا replay پس از failure همان ردیف‌ها را بازنویسی کند

Answer

افزودن ردیف جدید با UUID تصادفی برای هر رکورد خروجی

Answer

غیرفعال کردن checkpoint تا هیچ replay‌ای رخ ندهد

Answer

نوشتن خروجی فقط وقتی job به‌طور کامل متوقف شود