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

Question 1

تفاوت اصلی ارتباط synchronous و asynchronous بین سرویس‌ها چیست؟

Accepted Answer

در sync فرستنده منتظر پاسخ می‌ماند؛ در async پیام را می‌فرستد و ادامه می‌دهد

Answer

در sync از HTTP استفاده می‌شود و در async همیشه از TCP خام

Answer

در async پیام‌ها هیچ‌وقت گم نمی‌شوند ولی در sync ممکن است گم شوند

Answer

در sync سرویس‌ها مستقل‌اند ولی در async به هم وابسته می‌شوند

Question 2

مهم‌ترین مزیت معماری‌ای که سرویس‌ها از طریق یک message broker با هم حرف می‌زنند چیست؟

Accepted Answer

کاهش coupling زمانی؛ مصرف‌کننده لازم نیست همان لحظه در دسترس باشد

Answer

حذف کامل نیاز به مدیریت خطا و retry در سرویس‌ها

Answer

تضمین اینکه همه داده‌ها همیشه فوراً در همه سرویس‌ها consistent باشند

Answer

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

Question 3

در یک message queue کلاسیک (point-to-point) با چند consumer، هر پیام معمولاً به چه کسی تحویل داده می‌شود؟

Accepted Answer

فقط به یکی از consumerها

Answer

به همه consumerها به‌صورت همزمان

Answer

به consumerی که اول subscribe کرده، برای همیشه

Answer

به هیچ consumerی تا وقتی همه آماده شوند

Question 4

در مدل publish/subscribe، یک event منتشرشده به چه کسانی می‌رسد؟

Accepted Answer

هر subscriber یک کپی از event را دریافت می‌کند

Answer

فقط سریع‌ترین subscriber آن را دریافت می‌کند

Answer

فقط subscriberی که publisher مستقیماً انتخاب کند

Answer

event فقط ذخیره می‌شود و به کسی ارسال نمی‌شود

Question 5

تفاوت یک event با یک command در سیستم‌های پیام‌محور چیست؟

Accepted Answer

event بیان می‌کند چیزی رخ داده؛ command درخواست انجام کاری است

Answer

event همیشه sync است ولی command همیشه async ارسال می‌شود

Answer

event فقط یک گیرنده دارد ولی command به همه broadcast می‌شود

Answer

event قابل ذخیره نیست ولی command در log ذخیره می‌شود

Question 6

نقش message broker در یک معماری event-driven چیست؟

Accepted Answer

دریافت، نگهداری و مسیریابی پیام‌ها بین producerها و consumerها

Answer

اجرای business logic سرویس‌ها به‌جای خود سرویس‌ها

Answer

جایگزینی دیتابیس اصلی هر سرویس برای ذخیره state

Answer

توزیع بار درخواست‌های HTTP بین نمونه‌های یک سرویس

Question 7

در سیستم‌های pub/sub، «topic» چیست؟

Accepted Answer

یک کانال نام‌دار که پیام‌های یک دسته در آن منتشر می‌شوند

Answer

یک consumer خاص که مسئول پردازش همه پیام‌هاست

Answer

یک فیلد اجباری در body هر پیام برای احراز هویت

Answer

یک جدول در دیتابیس producer برای ذخیره پیام‌ها

Question 8

الگوی fan-out در معماری event-driven به چه معناست؟

Accepted Answer

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

Answer

چند پیام کوچک در یک پیام بزرگ ترکیب و یک‌جا ارسال می‌شوند

Answer

پیام‌های ناموفق به یک صف جداگانه برای بررسی منتقل می‌شوند

Answer

consumer سرعت producer را با فرستادن سیگنال کاهش می‌دهد

Question 9

هدف اصلی تقسیم یک topic به چند partition (مثلاً در Kafka) چیست؟

Accepted Answer

امکان پردازش موازی و scale افقی throughput

Answer

تضمین ترتیب سراسری همه پیام‌های آن topic

Answer

رمزنگاری پیام‌ها با کلیدهای متفاوت در هر partition

Answer

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

Question 10

Kafka ترتیب پیام‌ها را در چه محدوده‌ای تضمین می‌کند؟

Accepted Answer

داخل هر partition

Answer

در کل topic، بین همه partitionها

Answer

در کل cluster، بین همه topicها

Answer

هیچ تضمینی برای ترتیب وجود ندارد

Question 11

اگر بخواهیم همه eventهای یک سفارش خاص به ترتیب پردازش شوند، چه کار باید کرد؟

Accepted Answer

از `orderId` به‌عنوان partition key استفاده کنیم

Answer

پیام‌ها را به‌صورت round-robin بین partitionها پخش کنیم

Answer

برای هر event یک topic جداگانه بسازیم

Answer

تعداد consumerها را از تعداد partitionها بیشتر کنیم

Question 12

در Kafka، consumerهای یک consumer group چگونه پیام‌های یک topic را بین خود تقسیم می‌کنند؟

Accepted Answer

هر partition در هر لحظه فقط به یک consumer از group اختصاص دارد

Answer

هر پیام به همه consumerهای group تحویل داده می‌شود

Answer

هر consumer پیام‌ها را به‌صورت تصادفی از هر partition برمی‌دارد

Answer

فقط consumer اول کار می‌کند و بقیه همیشه standby هستند

Question 13

delivery semantics از نوع «at-most-once» به چه معناست؟

Accepted Answer

پیام ممکن است گم شود ولی هرگز تکراری تحویل نمی‌شود

Answer

پیام هرگز گم نمی‌شود ولی ممکن است تکراری تحویل شود

Answer

پیام دقیقاً یک بار و بدون هیچ استثنایی تحویل می‌شود

Answer

پیام حداکثر یک بار در روز برای consumer ارسال می‌شود

Question 14

در delivery از نوع «at-least-once»، consumer باید برای چه چیزی آماده باشد؟

Accepted Answer

دریافت پیام‌های تکراری

Answer

از دست رفتن بخشی از پیام‌ها

Answer

دریافت پیام‌ها با محتوای خراب‌شده

Answer

دریافت پیام‌های topicهای دیگر

Question 15

«idempotent consumer» یعنی چه؟

Accepted Answer

consumerی که پردازش چندباره یک پیام، همان نتیجه پردازش یک‌باره را دارد

Answer

consumerی که هر پیام را فقط یک بار از broker درخواست می‌کند

Answer

consumerی که هیچ state یا دیتابیسی برای خودش ندارد

Answer

consumerی که پیام‌ها را بدون ack کردن پردازش می‌کند

Question 16

چرا تحویل «exactly-once» واقعی در سیستم‌های توزیع‌شده دشوار است؟

Accepted Answer

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

Answer

چون brokerها اجازه ارسال بیش از یک پیام در ثانیه را نمی‌دهند

Answer

چون پیام‌ها همیشه در مسیر رمزنگاری و رمزگشایی تغییر می‌کنند

Answer

چون consumerها فقط می‌توانند پیام‌ها را به‌صورت batch بخوانند

Question 17

acknowledgement (ack) توسط consumer به broker چه چیزی را اعلام می‌کند؟

Accepted Answer

پیام با موفقیت پردازش شده و می‌توان آن را تحویل‌شده در نظر گرفت

Answer

consumer آماده است تا پیام بعدی را دقیقاً یک دقیقه بعد بگیرد

Answer

پیام باید فوراً به همه consumerهای دیگر هم ارسال شود

Answer

producer باید پیام را دوباره با اولویت بالاتر ارسال کند

Question 18

dead-letter queue (DLQ) برای چه استفاده می‌شود؟

Accepted Answer

نگهداری پیام‌هایی که بعد از چند تلاش پردازش نشده‌اند

Answer

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

Answer

ارسال پیام‌های با اولویت بالا قبل از بقیه پیام‌ها

Answer

ذخیره موقت پیام‌ها وقتی producer آفلاین است

Question 19

«poison message» به چه پیامی گفته می‌شود؟

Accepted Answer

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

Answer

پیامی که حاوی کد مخرب برای حمله به broker است

Answer

پیامی که بیش از حد مجاز در صف منتظر مانده است

Answer

پیامی که producer آن را دو بار پشت سر هم فرستاده است

Question 20

چرا retry پیام‌های ناموفق معمولاً با exponential backoff انجام می‌شود؟

Accepted Answer

تا به سرویس وابسته‌ی مشکل‌دار فرصت بازیابی بدهیم و آن را غرق نکنیم

Answer

تا ترتیب پیام‌ها در کل topic به‌طور کامل حفظ شود

Answer

تا پیام‌های تکراری به‌طور خودکار از صف حذف شوند

Answer

تا پیام‌ها سریع‌تر از حالت عادی به consumer برسند

Question 21

وقتی ترافیک ورودی به‌صورت ناگهانی چند برابر می‌شود، وجود یک queue بین API و worker چه کمکی می‌کند؟

Accepted Answer

پیک را جذب می‌کند تا workerها با سرعت ثابت خودشان کار را پردازش کنند

Answer

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

Answer

تعداد workerها را بدون نیاز به autoscaling چند برابر می‌کند

Answer

زمان پردازش هر پیام را با فشرده‌سازی آن کاهش می‌دهد

Question 22

backpressure در سیستم‌های پیام‌محور و streaming چیست؟

Accepted Answer

مکانیزمی که مصرف‌کننده کند، سرعت تولید داده را محدود می‌کند

Answer

فشرده‌سازی پیام‌ها برای کاهش مصرف پهنای باند شبکه

Answer

ارسال دوباره پیام‌ها از consumer به producer برای تأیید

Answer

افزایش خودکار تعداد partitionها هنگام افزایش بار

Question 23

یک ویژگی مهم distributed log (مثل Kafka) که در queueهای سنتی معمولاً وجود ندارد چیست؟

Accepted Answer

پیام‌ها بعد از مصرف باقی می‌مانند و می‌توان آن‌ها را دوباره خواند

Answer

هر پیام فقط توسط یک consumer در کل سیستم خوانده می‌شود

Answer

پیام‌ها بلافاصله پس از تحویل به consumer حذف می‌شوند

Answer

broker برای هر consumer وضعیت ack تک‌تک پیام‌ها را نگه می‌دارد

Question 24

در Kafka، «offset» چیست؟

Accepted Answer

شماره ترتیبی هر پیام در یک partition که موقعیت خواندن را نشان می‌دهد

Answer

فاصله زمانی بین ارسال پیام توسط producer و دریافت آن

Answer

تعداد پیام‌هایی که consumer در هر batch دریافت می‌کند

Answer

شناسه یکتای هر broker در داخل cluster

Question 25

«consumer lag» نشان‌دهنده چیست؟

Accepted Answer

فاصله بین آخرین پیام نوشته‌شده و آخرین پیام پردازش‌شده توسط consumer

Answer

زمان لازم برای برقراری اتصال consumer به broker

Answer

تعداد consumerهایی که در group از کار افتاده‌اند

Answer

مدت زمانی که پیام در شبکه بین brokerها در حرکت است

Question 26

در الگوی event sourcing، state فعلی یک موجودیت چگونه به دست می‌آید؟

Accepted Answer

با اجرای دوباره (replay) همه eventهای ثبت‌شده برای آن موجودیت

Answer

با خواندن آخرین ردیف به‌روزشده در یک جدول relational

Answer

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

Answer

با نگه‌داشتن state فقط در حافظه و بدون هیچ ذخیره‌سازی

Question 27

ایده اصلی CQRS چیست؟

Accepted Answer

جدا کردن مدل نوشتن (command) از مدل خواندن (query)

Answer

استفاده از یک دیتابیس مشترک برای همه سرویس‌ها

Answer

cache کردن همه queryها در لایه CDN

Answer

تبدیل همه عملیات نوشتن به فراخوانی‌های sync

Question 28

وقتی سرویس‌ها از طریق event داده‌هایشان را همگام می‌کنند، معمولاً چه نوع consistencyای داریم؟

Accepted Answer

eventual consistency؛ داده‌ها پس از مدتی کوتاه همگام می‌شوند

Answer

strong consistency؛ همه سرویس‌ها همیشه همان داده را می‌بینند

Answer

linearizability کامل بین همه سرویس‌ها و دیتابیس‌ها

Answer

هیچ consistencyای؛ داده‌ها هرگز همگام نمی‌شوند

Question 29

webhook چگونه کار می‌کند؟

Accepted Answer

سرویس منبع هنگام رخ دادن event یک درخواست HTTP به URL ثبت‌شده می‌فرستد

Answer

کلاینت هر چند ثانیه یک‌بار وضعیت را از سرور درخواست می‌کند

Answer

کلاینت یک اتصال دوطرفه دائمی با سرور باز نگه می‌دارد

Answer

سرور eventها را در یک فایل ذخیره می‌کند تا کلاینت دانلود کند

Question 30

عیب اصلی short polling برای دریافت به‌روزرسانی‌ها چیست؟

Accepted Answer

درخواست‌های زیاد بی‌نتیجه و تأخیر وابسته به فاصله polling

Answer

نیاز به پشتیبانی مرورگر از پروتکل‌های خاص و جدید

Answer

عدم امکان استفاده از HTTP و نیاز به TCP خام

Answer

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

Question 31

long polling چه تفاوتی با short polling دارد؟

Accepted Answer

سرور درخواست را تا رسیدن داده جدید یا timeout باز نگه می‌دارد

Answer

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

Answer

اتصال به WebSocket ارتقا پیدا می‌کند و دوطرفه می‌شود

Answer

سرور داده‌ها را به‌صورت batch هر یک ساعت ارسال می‌کند

Question 32

ویژگی اصلی WebSocket چیست؟

Accepted Answer

یک اتصال پایدار و full-duplex بین کلاینت و سرور

Answer

یک درخواست HTTP یک‌طرفه که پس از هر پاسخ بسته می‌شود

Answer

یک صف پیام سمت سرور برای ارتباط بین microserviceها

Answer

یک فرمت فشرده‌سازی برای کاهش حجم پاسخ‌های JSON

Question 33

Server-Sent Events (SSE) برای چه سناریویی مناسب است؟

Accepted Answer

ارسال یک‌طرفه به‌روزرسانی‌ها از سرور به مرورگر روی HTTP

Answer

ارتباط دوطرفه با latency بسیار پایین برای بازی‌های چندنفره

Answer

انتقال فایل‌های حجیم باینری از کلاینت به سرور

Answer

ارتباط async بین microserviceها از طریق broker

Question 34

برای یک اپلیکیشن چت که کاربران مدام پیام می‌فرستند و دریافت می‌کنند، کدام روش ارتباط با مرورگر مناسب‌تر است؟

Accepted Answer

WebSocket، چون ارتباط دوطرفه و کم‌تأخیر روی یک اتصال دارد

Answer

short polling هر ۳۰ ثانیه، چون پیاده‌سازی آن ساده‌تر است

Answer

webhook، چون سرور می‌تواند مستقیماً مرورگر را صدا بزند

Answer

ایمیل، چون تحویل پیام را همیشه تضمین می‌کند

Question 35

الگوی saga برای حل چه مشکلی استفاده می‌شود؟

Accepted Answer

مدیریت یک تراکنش business که بین چند سرویس با دیتابیس جدا پخش شده

Answer

افزایش سرعت queryهای خواندن با استفاده از cache توزیع‌شده

Answer

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

Answer

رمزنگاری پیام‌ها هنگام عبور از broker

Question 36

در saga از نوع choreography، مراحل چگونه هماهنگ می‌شوند؟

Accepted Answer

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

Answer

یک سرویس مرکزی به هر سرویس دستور می‌دهد چه کاری انجام دهد

Answer

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

Answer

کاربر هر مرحله را به‌صورت دستی تأیید و اجرا می‌کند

Question 37

در saga از نوع orchestration، چه کسی جریان را کنترل می‌کند؟

Accepted Answer

یک orchestrator مرکزی که به سرویس‌ها command می‌فرستد

Answer

هر سرویس به‌طور مستقل و بدون آگاهی از بقیه

Answer

message broker با قوانین routing داخلی خودش

Answer

دیتابیس مشترک از طریق triggerها و stored procedureها

Question 38

compensating transaction در saga چیست؟

Accepted Answer

عملیاتی که اثر یک مرحله موفق قبلی را از نظر business خنثی می‌کند

Answer

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

Answer

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

Answer

تراکنشی که هزینه پردازش پیام را به consumer برمی‌گرداند

Question 39

مشکل «dual write» چیست؟ (نوشتن در دیتابیس و سپس publish کردن event به broker)

Accepted Answer

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

Answer

داده دو بار در دیتابیس ذخیره می‌شود و فضا هدر می‌رود

Answer

broker پیام را دو بار برای همه consumerها ارسال می‌کند

Answer

دو سرویس هم‌زمان یک رکورد را قفل کرده و deadlock رخ می‌دهد

Question 40

Change Data Capture (CDC) چیست؟

Accepted Answer

ثبت تغییرات دیتابیس و انتشار آن‌ها به‌صورت جریانی از event

Answer

گرفتن backup کامل از دیتابیس در فواصل زمانی منظم

Answer

رمزنگاری داده‌های حساس قبل از ذخیره در دیتابیس

Answer

فشرده‌سازی جدول‌های قدیمی برای کاهش حجم دیتابیس

Question 41

چرا ساختار (schema) eventها باید مثل یک قرارداد (contract) با دقت مدیریت شود؟

Accepted Answer

چون consumerهای زیادی، گاهی ناشناخته، به ساختار آن وابسته‌اند

Answer

چون brokerها eventهای بدون schema را همیشه رد می‌کنند

Answer

چون schema تعیین می‌کند event به کدام partition برود

Answer

چون بدون schema نمی‌توان eventها را رمزنگاری کرد

Question 42

کدام تغییر در schema یک event معمولاً برای consumerهای موجود امن است؟

Accepted Answer

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

Answer

تغییر نام یک فیلد پرکاربرد موجود

Answer

تغییر نوع یک فیلد از عدد به رشته

Answer

حذف یک فیلد اجباری که consumerها می‌خوانند

Question 43

تفاوت stream processing با batch processing چیست؟

Accepted Answer

stream داده را پیوسته و هنگام رسیدن پردازش می‌کند؛ batch روی مجموعه‌ای محدود و دوره‌ای

Answer

stream فقط برای داده‌های کوچک و batch فقط برای داده‌های بزرگ است

Answer

stream همیشه دقیق‌تر از batch است چون داده را دو بار می‌خواند

Answer

batch نیاز به broker دارد ولی stream مستقیماً از فایل می‌خواند

Question 44

tumbling window در stream processing چیست؟

Accepted Answer

پنجره‌های زمانی با اندازه ثابت و بدون هم‌پوشانی، مثل هر ۱ دقیقه

Answer

پنجره‌هایی که با هر event جدید به اندازه یک event جلو می‌روند

Answer

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

Answer

پنجره‌ای واحد که از ابتدای stream تا ابد باز می‌ماند

Question 45

تفاوت event time و processing time چیست؟

Accepted Answer

event time زمان رخ دادن واقعی است؛ processing time زمان پردازش در سیستم

Answer

event time زمان ارسال به broker است؛ processing time زمان ذخیره روی دیسک

Answer

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

Answer

event time فقط در batch و processing time فقط در streaming کاربرد دارد

Question 46

چرا در پیام‌ها یک correlation ID قرار می‌دهیم؟

Accepted Answer

برای ردیابی یک جریان کاری در میان چند سرویس و پیام async

Answer

برای تعیین اینکه پیام در کدام partition ذخیره شود

Answer

برای رمزنگاری پیام با یک کلید مخصوص هر کاربر

Answer

برای افزایش اولویت پیام در صف broker

Question 47

در صف‌هایی مثل Amazon SQS، «visibility timeout» چه کاری انجام می‌دهد؟

Accepted Answer

پیام دریافت‌شده را موقتاً از دید بقیه consumerها پنهان می‌کند

Answer

پیام‌های قدیمی‌تر از یک مدت مشخص را برای همیشه حذف می‌کند

Answer

تعیین می‌کند producer چقدر منتظر تأیید broker بماند

Answer

مدت زمان باز ماندن اتصال consumer به صف را محدود می‌کند

Question 48

ساده‌ترین راه افزایش throughput پردازش پیام‌های یک queue چیست؟

Accepted Answer

اضافه کردن consumerهای بیشتر که روی همان queue رقابت می‌کنند

Answer

افزایش اندازه هر پیام تا اطلاعات بیشتری منتقل شود

Answer

تبدیل queue به یک topic با تنها یک subscriber

Answer

غیرفعال کردن ack تا پیام‌ها سریع‌تر حذف شوند

Question 49

تفاوت «event notification» با «event-carried state transfer» چیست؟

Accepted Answer

اولی فقط خبر تغییر و یک شناسه را می‌دهد؛ دومی داده کامل لازم را هم حمل می‌کند

Answer

اولی از طریق HTTP و دومی فقط از طریق Kafka ارسال می‌شود

Answer

اولی برای command و دومی برای query استفاده می‌شود

Answer

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

Question 50

برای اینکه پیام‌ها با restart شدن broker از دست نروند، چه چیزی لازم است؟

Accepted Answer

پیام‌ها persistent باشند و روی دیسک (و ترجیحاً چند replica) نوشته شوند

Answer

پیام‌ها فقط در حافظه broker با حجم زیاد نگه داشته شوند

Answer

consumerها پیام‌ها را قبل از پردازش ack کنند

Answer

producer پیام‌ها را بدون انتظار برای تأیید ارسال کند