Senior Event-Driven & Streaming Interview Questions (50 MCQs)

Question 1

For throughput, you run the outbox relay on 4 instances, each grabbing batches. Consumers report `OrderShipped` sometimes arriving before `OrderPaid`. What is the best fix?

Accepted Answer

Shard the relay by aggregate id so one instance publishes each aggregate's events in order

Answer

Add more relay instances so each event is published faster

Answer

Add `created_at` to events and ask consumers to sort them themselves

Answer

Drop the relay and publish directly to the broker inside the transaction

Question 2

You want to build a new search index via CDC from a 500M-row table while writes continue. What is the key challenge and the right approach?

Accepted Answer

Aligning the initial snapshot with the change stream; snapshot at a known log position, then stream from there

Answer

CDC only yields new changes, so old rows can never be transferred

Answer

The database must be fully read-only until the snapshot ends; there is no alternative

Answer

Just read all rows with `SELECT *`; change ordering does not matter

Question 3

In an event store with 5 years of data, `AddressChanged` must change (splitting `address` into several fields). What is the preferred approach?

Accepted Answer

An upcaster that converts old-version events to the new version on read

Answer

Directly UPDATE all old events in the event store to the new shape

Answer

Delete the old events and replace them with a new snapshot

Answer

Keep logic for both versions in every aggregate and projection forever

Question 4

Your event-sourced system is append-only, but GDPR requires you to 'forget' a user's personal data. Which solution is common?

Accepted Answer

Crypto-shredding: encrypt PII with a per-user key and delete the key

Answer

Append a `UserForgotten` event and keep old events unchanged

Answer

Reduce the whole event store's retention to 30 days

Answer

Hide the user's data only in read models and the UI

Question 5

While rebuilding a projection by replaying all history, a handler that sends welcome emails re-sent them to millions of users. What is the design lesson?

Accepted Answer

Separate external side effects from projections and disable or dedup them during replay

Answer

Never replay; fix projections manually instead

Answer

Send emails synchronously inside the aggregate so they never repeat

Answer

Delete all email-related events from the store before replaying

Question 6

You changed an aggregate's `apply` logic (e.g. how balance is computed). What problem do existing snapshots cause?

Accepted Answer

They reflect state computed with the old logic and must be versioned and rebuilt

Answer

No problem, since snapshots are independent of aggregate logic

Answer

Events after the snapshot are automatically deleted

Answer

Snapshots make new events unwritable in the store

Question 7

Two concurrent requests withdraw from one account and both see sufficient balance. How does an event store prevent overdraft?

Accepted Answer

Append with an expected version; if the stream changed meanwhile, the write is rejected and retried

Answer

A global lock on the entire event store during each transaction

Answer

Both events are written and later fixed with a compensating event

Answer

Consumers drop duplicate events when reading

Question 8

Rebuilding a heavily used read model from events takes 6 hours. How do you change it without downtime?

Accepted Answer

Build the new projection in parallel in a separate table, catch up to head, then switch reads

Answer

Truncate the current table and run the rebuild during off-peak hours

Answer

Apply only new events with the new logic and leave old data as is

Answer

Remove the read model and run all queries directly on the event store

Question 9

A Kafka Streams app with `processing.guarantee=exactly_once_v2` calls an external payment API per event. Are payments exactly-once?

Accepted Answer

No; the guarantee covers only Kafka state and topics, so the external call needs an idempotency key

Answer

Yes; the Kafka transaction also rolls back HTTP calls

Answer

Yes, provided the replication factor is at least 3

Answer

No; because Kafka exactly-once only works for producers, not consumers

Question 10

How does Flink provide exactly-once for internal state and a transactional sink like Kafka?

Accepted Answer

Distributed checkpoints via barriers plus a two-phase-commit sink that commits on checkpoint completion

Answer

Synchronously storing each record in an external DB before processing the next

Answer

Deduplicating all output records at the final consumer by content hash

Answer

Processing each record on two TaskManagers and comparing results

Question 11

In a Flink pipeline with a transactional Kafka sink, some output was lost after a long job outage. What is the most likely configuration cause?

Accepted Answer

`transaction.timeout.ms` was shorter than checkpoint-to-recovery time, so the broker aborted the transaction

Answer

The output topic's replication factor was set too high

Answer

Downstream consumers were reading with `read_uncommitted`

Answer

Job parallelism exceeded the source's partition count

Question 12

A Flink job reads a 12-partition topic. One partition gets no data at night and windows stop closing. What is the cause and fix?

Accepted Answer

The overall watermark is the minimum across partitions; mark the idle partition with an idleness timeout

Answer

Flink automatically pauses checkpoints at night

Answer

There are too many partitions; reduce to a single one

Answer

Switch all windows from event time to ingestion time

Question 13

A team defined windows on processing time for simplicity and now replays a month of data to fix a bug. What happens?

Accepted Answer

A month of data collapses into a few minute-long windows and results differ entirely from the original

Answer

Results reproduce exactly like the first run since the data is the same

Answer

Flink refuses the replay because processing time is not repeatable

Answer

Only latency increases; window assignment is unchanged

Question 14

With event-time session windows and a 30-minute gap, a late event lands between two existing sessions of a user. What is the correct behavior?

Accepted Answer

If it is within the gap of both, the two sessions merge and a corrected result is emitted

Answer

The event is always added to the newer session and the older stays fixed

Answer

The event is treated as a separate one-record session

Answer

Session windows can never accept late events and drop them

Question 15

You want to join an ad-click stream with an impressions stream. What is the most important design decision?

Accepted Answer

Bounding the join to a time interval (windowed/interval join) to keep state bounded

Answer

Keeping all impressions in state forever so no join is ever missed

Answer

Converting both streams to daily batches and joining at day end

Answer

Joining on processing time to reduce complexity

Question 16

In Kafka Streams, joining an orders KStream (key: `orderId`) with a customers KTable (key: `customerId`) fails or gives wrong results. Why?

Accepted Answer

Joins require co-partitioning; the stream must be rekeyed by `customerId` and repartitioned

Answer

A KTable can only be joined with another KTable

Answer

Joins only work when exactly-once is enabled

Answer

The KStream must first be converted to a compacted topic

Question 17

A celebrity account produces 30% of `likes` events and its partition has high lag. The business only needs like counts. What is best?

Accepted Answer

Salt the key (e.g. `postId#0..N`) and aggregate in two stages, partial then final

Answer

Add more consumers without changing the partition key

Answer

Move all that account's events to a single-partition topic

Answer

Increase that topic's retention so the consumer can catch up

Question 18

A 200-instance consumer group on Kubernetes fully stops consuming for minutes on every rolling deploy. Which combination helps most?

Accepted Answer

Static membership with `group.instance.id` and the cooperative sticky assignor

Answer

Lowering `session.timeout.ms` to a few seconds for faster detection

Answer

Using auto-commit with a one-millisecond interval

Answer

Creating a new consumer group on every deploy

Question 19

A consumer sometimes processes batches taking 8 minutes, with `max.poll.interval.ms` at 5 minutes. What symptom do you see?

Accepted Answer

The consumer is kicked from the group, a rebalance occurs, and the batch is reprocessed elsewhere

Answer

Kafka automatically sends the batch's messages to a DLQ after 5 minutes

Answer

The broker disconnects the producer to relieve pressure

Answer

Offsets automatically advance and messages are lost

Question 20

A saga orchestrator crashes after sending `ReserveInventory` but before recording it in its state. What must a correct design guarantee?

Accepted Answer

Saga state is durable, commands go through an outbox, and participants are idempotent

Answer

The orchestrator must be stateless so crashes do not affect it

Answer

After restart, all unfinished sagas are compensated without checks

Answer

Commands must be sent synchronously, waiting for the final reply

Question 21

In an order saga, steps are 'reserve stock', 'charge card', and 'send confirmation email'. Email cannot be compensated. What is the correct step ordering from a saga design view?

Accepted Answer

Compensatable steps first, then the pivot (charge), and retryable non-compensatable steps last

Answer

Send the email first so the user is informed sooner, then the rest

Answer

Order does not matter since all steps are eventually compensated

Answer

Run all steps in parallel to minimize latency

Question 22

In a hotel booking saga, another user sees a room reserved by a first saga that is being compensated and may be freed. Which countermeasure fits?

Accepted Answer

Semantic lock: flag the record as `PENDING` with defined behavior for other requests

Answer

Use a `SERIALIZABLE` transaction spanning all services

Answer

Remove compensation and convert the saga to two-phase commit

Answer

Increase the partition count of the booking topic

Question 23

In a choreographed system, A's `PriceChanged` triggers B, B's `StockAdjusted` triggers C, and C changes the price in A again. What is the main risk?

Accepted Answer

An infinite event loop (event storm) and hidden coupling between services

Answer

The broker automatically drops messages because of the cycle

Answer

Only latency rises slightly with no other serious issue

Answer

Events get delivered point-to-point instead of pub/sub

Question 24

Your topic has infinite retention and new consumers read from the beginning. The current compatibility mode is `BACKWARD`. Why might it be insufficient?

Accepted Answer

It checks only against the previous version, not all of them; `BACKWARD_TRANSITIVE` is needed

Answer

`BACKWARD` does not allow adding any new fields

Answer

`BACKWARD` is only valid for compacted topics

Answer

The schema registry is disabled for infinite-retention topics

Question 25

A schema change is only `FORWARD` compatible (e.g. removing an optional field). What is the safe deploy order?

Accepted Answer

Producers first, since old consumers can read the new data

Answer

Consumers first, since old producers produce the new data

Answer

All producers and consumers must deploy at exactly the same time

Answer

Order does not matter since the registry performs the conversion

Question 26

In a kappa architecture, a bug is found in computation logic and the last 90 days of results must be corrected. What is the right method?

Accepted Answer

Run a new job version from the 90-days-ago offset into a new output, then switch consumers once caught up

Answer

Stop the current job, reset offsets, and overwrite the same output table

Answer

Write a separate batch job with different code to fix historical data

Answer

Apply the new logic only going forward since streams cannot be reprocessed

Question 27

When might lambda architecture still be a reasonable choice over kappa?

Accepted Answer

When reprocessing all history via the stream processor is very costly and specialized batch algorithms are needed

Answer

When the team wants to maintain only one codebase for all processing

Answer

When input volume is small and log retention is unlimited and cheap

Answer

When low latency has no business importance at all

Question 28

In a ledger where per-account event order is critical, account X's event #10 went to the DLQ but #11 and #12 were processed. What is a better design?

Accepted Answer

After DLQ-ing an event, park subsequent events for the same key until it is resolved

Answer

Remove the DLQ and halt the whole partition until manual repair

Answer

Redrive DLQ events later regardless of ordering

Answer

Make retries unlimited so no event reaches the DLQ

Question 29

In a Flink job, the Elasticsearch sink slows down. How does backpressure propagate, and what is the final effect on Kafka?

Accepted Answer

Network buffers between operators fill, slowing upstream until the source reads less and Kafka lag grows

Answer

Flink drops excess data to keep throughput constant

Answer

The source keeps its pace and data piles up in heap until OOM

Answer

Kafka automatically throttles the producers

Question 30

At peak, an ingestion service puts requests in an unbounded in-memory queue; latency reaches minutes and it eventually OOMs. What design principle was violated?

Accepted Answer

Queues must be bounded, applying backpressure or load shedding (e.g. `429`) when full

Answer

Queues should always be in memory to minimize latency

Answer

Use direct sync calls to the database instead of a queue

Answer

Heap size should grow dynamically without limit

Question 31

After a 2-hour payment outage, 5M messages piled up in the DLQ and retry topics. What is the risk of redriving all at once, and the right approach?

Accepted Answer

Re-overwhelming the freshly recovered service; redrive with a rate limit and gradual ramp-up

Answer

No risk, since the messages are idempotent

Answer

Messages will be deleted by retention, so redrive as fast as possible

Answer

The broker does not allow redriving more than 1000 messages

Question 32

You run an SSE notification service on 20 instances behind a load balancer. An event for user X is produced on instance 3, but X's connection is on instance 17. What is the architectural fix?

Accepted Answer

A pub/sub backplane (like Redis or Kafka) that routes the event to the instance holding the connection

Answer

Enable sticky sessions so all events go to instance 17

Answer

Replace SSE with short polling to remove persistent connections

Answer

Run a single large instance so all connections live on it

Question 33

Your WebSocket service holds 500K concurrent connections. Every deploy, backends collapse under a reconnect wave. Which combination helps most?

Accepted Answer

Gradual connection draining, client reconnect with exponential backoff and jitter, and resuming from the last event id

Answer

Dropping all connections at once so the deploy finishes faster

Answer

Raising connection timeouts to 24 hours

Answer

Replacing WebSocket with webhooks for browser clients

Question 34

In a webhook platform for thousands of customers, one customer's endpoint times out at 30 seconds and delivery slows for everyone. What is the root cause and fix?

Accepted Answer

A shared queue and workers; use per-endpoint isolation with concurrency limits and circuit breakers

Answer

Too few partitions; double the partition count

Answer

Missing HMAC signatures; add signing

Answer

A short timeout; raise it to 5 minutes

Question 35

Your consumer stores processed message ids in Redis with a 24-hour TTL. After a replay from 3 days ago, duplicate payments were recorded. What is the design lesson?

Accepted Answer

The dedup window must cover the maximum possible redelivery/replay span, or idempotency must live durably in business data

Answer

Redis is unsuitable for dedup because it always loses data

Answer

Replay must never be done in financial systems

Answer

The TTL should be shortened to use less memory

Question 36

A consumer first updates a balance in PostgreSQL, then records the message id in Redis. What failure window exists and what is the correct fix?

Accepted Answer

A crash between the writes causes re-application; record the message id in the same PostgreSQL transaction

Answer

There is no window since Redis is faster than PostgreSQL

Answer

Swap the order so Redis is written before PostgreSQL

Answer

Commit the offset before both writes

Question 37

A product manager wants 'all system events processed in exact global order'. What is the appropriate architectural response?

Accepted Answer

Global order means one partition, one consumer, and a throughput ceiling; find the real ordering boundary (e.g. per account)

Answer

Adding partitions and consumers keeps global order while increasing throughput

Answer

Server clock timestamps can guarantee exact global order at any scale

Answer

Kafka guarantees global order across all partitions by default

Question 38

You set up two Kafka clusters in two regions as active-active with bidirectional topic replication. What is the most important problem to prevent?

Accepted Answer

Infinite replication loops; prevent via region-prefixed topics or origin headers

Answer

A different broker count between the two regions

Answer

Different message compression in each region

Answer

Needing a separate schema registry per region

Question 39

In the 'listen to yourself' pattern, a service only publishes the event and then updates its DB by consuming it. What is its main trade-off versus the outbox?

Accepted Answer

It removes the dual write, but the service itself becomes eventually consistent and read-your-writes gets hard

Answer

It removes the need for a broker entirely

Answer

It guarantees invariant validation happens atomically before publishing

Answer

It only works in systems that support two-phase commit

Question 40

A Kafka transactional producer aborts transactions, yet a downstream consumer still processes those messages. What is the cause?

Accepted Answer

The consumer reads with `isolation.level=read_uncommitted` (the default) and should use `read_committed`

Answer

Abort in Kafka removes messages only from the partition leader, not replicas

Answer

The consumer group must share the producer's name

Answer

Transactions are only valid on compacted topics

Question 41

A producer instance was presumed dead due to a long GC pause and its replacement started. The old instance wakes and tries to write. How does Kafka prevent duplicate output?

Accepted Answer

Via a stable `transactional.id` and epoch; the new instance bumps the epoch and the zombie gets fenced

Answer

The broker permanently bans any producer after 30 seconds of inactivity

Answer

Consumers receive both instances' messages and dedup by content hash

Answer

Kafka cannot detect this; it must be solved with a ZooKeeper lock

Question 42

Video transcoding jobs take 1 second to 10 minutes and have no ordering. The team uses Kafka with classic consumer groups; workers sit idle while lag is high. What is wrong?

Accepted Answer

The per-partition offset model fits poorly for variable-duration work; a queue with per-message acks (or Kafka share groups) fits better

Answer

Topic retention should be increased so jobs are not lost

Answer

Exactly-once should be enabled so workers get faster

Answer

All jobs should be placed into a single partition

Question 43

A business customer's account aggregate has millions of events after years, and even with snapshots concurrency conflicts are frequent. What modeling fix fits?

Accepted Answer

Split the stream with 'closing the books' (e.g. periodic streams with a carried-over balance event) or smaller aggregates

Answer

Delete events older than a year from the stream

Answer

Use a pessimistic lock on the whole aggregate for every operation

Answer

Save a snapshot after every event to prevent conflicts

Question 44

A Kafka Streams app with a 50GB state store takes about 40 minutes to restore from the changelog after each failover. What is the best improvement?

Accepted Answer

Standby replicas (`num.standby.replicas`) and persistent volumes to keep local state

Answer

Disabling the changelog topic so no restore is needed

Answer

Lowering the changelog's replication factor for faster reads

Answer

Switching the state store to in-memory without backup

Question 45

Fulfillment consumes both `OrderPlaced` (keyed by `orderId`) and `PaymentCaptured` (keyed by `paymentId`), and sometimes payment arrives before the order. What is a robust design?

Accepted Answer

Build the consumer as a state machine that accepts events in any order and waits until conditions are complete

Answer

Keep retrying the payment message until the order arrives, eventually DLQ-ing it

Answer

Put both events in one single-partition topic for global order

Answer

Trust event production timestamps and discard older ones

Question 46

Services build a local copy of customer data from `CustomerUpdated` events (7-day retention). A new service needs all 10M customers. What is the best design?

Accepted Answer

A compacted topic with each customer's latest state that the new service reads from the start

Answer

The new service sends 10M HTTP requests to the Customer API

Answer

Raise the current topic's retention to seven years and read from the start

Answer

Connect directly to the Customer DB and copy the table

Question 47

The orchestrator has received no reply from the payment service for a `ChargeCard` command after 30 seconds. What is the correct action?

Accepted Answer

The outcome is unknown; query status or retry with the same idempotency key, then decide to continue or compensate

Answer

Assume the payment failed and immediately cancel the order

Answer

Assume the payment succeeded and start shipping

Answer

Resend the command with a new idempotency key

Question 48

To preserve order, you put `OrderCreated`, `OrderPaid`, and `OrderCancelled` with different schemas in one topic. What schema registry setting is needed?

Accepted Answer

A `TopicRecordNameStrategy` subject naming (or a union schema) instead of the topic-based default

Answer

Disabling compatibility checks for that topic

Answer

Running a separate schema registry per event type

Answer

Converting all events to schemaless JSON

Question 49

A large partner wants 50M of your events daily and must resume where it left off after its own outages. Why might webhooks be a poor fit, and what is the alternative?

Accepted Answer

High-volume push puts retries and backlog on you; a pull-based event feed with a cursor fits better

Answer

Webhooks do not support HTTPS and are unsafe for sensitive data

Answer

Webhooks only work for events smaller than 1KB

Answer

Webhooks require the partner to keep a permanent WebSocket open

Question 50

Your sink is Cassandra, which does not support two-phase commit. How do you get effectively-once output from a checkpointing stream processor?

Accepted Answer

Idempotent upserts keyed deterministically so replays after failure overwrite the same rows

Answer

Inserting a new row with a random UUID for each output record

Answer

Disabling checkpoints so no replay ever happens

Answer

Writing output only when the job fully stops