Senior Message Queues & Async Interview Questions (50 MCQs)

Question 1

Why can't exactly-once delivery truly be guaranteed in a distributed system with external side effects?

Accepted Answer

The consumer can't atomically apply the effect and record the ack; a crash between them is ambiguous

Answer

Because brokers only use UDP

Answer

Because messages are always corrupted in transit

Answer

Because no broker supports acks

Question 2

What exactly does Kafka's exactly-once semantics (transactions) cover?

Accepted Answer

The read-process-write loop within Kafka: consuming, producing to topics and committing offsets atomically

Answer

Any external side effect like sending email or calling an API

Answer

Atomic writes to both PostgreSQL and Kafka

Answer

Ensuring a consumer polls each message only once

Question 3

How does Kafka's idempotent producer (`enable.idempotence=true`) prevent duplicates?

Accepted Answer

The broker uses the producer ID and per-partition sequence numbers to detect and drop duplicate retries

Answer

The producer scans the whole topic for an identical message before sending

Answer

The broker dedups based on a hash of message content

Answer

The consumer filters duplicates by key

Question 4

With `replication.factor=3`, `min.insync.replicas=2` and `acks=all`, what happens if two of three brokers go down?

Accepted Answer

Writes fail with `NotEnoughReplicas`, but committed data isn't lost

Answer

Writes continue with just one replica

Answer

Kafka creates new replicas elsewhere and carries on

Answer

Consumers can't read anymore either

Question 5

Why is `acks=all` alone (with `min.insync.replicas=1`) not enough for durability?

Accepted Answer

If the ISR shrinks to just the leader, `acks=all` is satisfied by one replica and losing the leader loses data

Answer

Because `acks=all` applies only to consumers

Answer

Because `acks=all` doesn't write to disk

Answer

Because `acks=all` only works in transactional mode

Question 6

When is a follower removed from the ISR (in-sync replicas)?

Accepted Answer

When it fails to catch up with the leader for longer than `replica.lag.time.max.ms`

Answer

When it has too many consumers

Answer

Every time a new message is produced

Answer

When the topic is compacted

Question 7

What trade-off does `unclean.leader.election.enable=true` make?

Accepted Answer

Higher availability at the risk of losing committed messages

Answer

Higher durability at the cost of throughput

Answer

Global ordering at the cost of latency

Answer

Better security at the cost of CPU

Question 8

On a Kafka producer without idempotence, why can `max.in.flight.requests.per.connection > 1` with retries break ordering?

Accepted Answer

Batch 1 fails and is retried while batch 2 succeeds, so batch 2 is written first

Answer

Because the broker sorts batches by size

Answer

Because each request goes to a random partition

Answer

Because the consumer reads batches in parallel

Question 9

In Kafka, how does `transactional.id` protect against zombie producers?

Accepted Answer

Each `initTransactions` bumps an epoch and the broker rejects requests from older epochs

Answer

Old producers are auto-removed after 5 minutes

Answer

The broker blocks the old producer's IP

Answer

Consumers filter the old producer's messages by timestamp

Question 10

With `isolation.level=read_uncommitted` (the default), what does a consumer see alongside a transactional producer?

Accepted Answer

It also sees messages from aborted and in-flight transactions

Answer

Only committed messages

Answer

No messages from transactional producers

Answer

Only control markers

Question 11

80% of traffic comes from one big customer and `customerId` is the partition key. What's the problem and a fix?

Accepted Answer

A hot partition forms; use a finer key (like `customerId:orderId`) if ordering is only needed at that level

Answer

No problem, Kafka rebalances load across partitions automatically

Answer

Increase the replication factor

Answer

Enable auto-commit

Question 12

In an ordered partition, one bad message blocks processing. If per-key order is critical, what's the best strategy?

Accepted Answer

Park that message and all later messages for the same key while other keys continue

Answer

Skip it and keep processing later messages for that key

Answer

Stop the whole consumer for all keys until manual fixing

Answer

Restart the broker

Question 13

How can a Kafka consumer exceed partition-count parallelism while preserving per-key order?

Accepted Answer

Process messages in parallel by key within a partition and commit only up to the lowest fully completed offset

Answer

Commit each message's offset as soon as processing starts

Answer

Use multiple consumer groups on one topic to split work

Answer

Enable auto-commit with a short interval

Question 14

What's the benefit of cooperative incremental rebalancing over eager rebalancing?

Accepted Answer

Only partitions that move are revoked; others keep consuming without a stop-the-world pause

Answer

Rebalances never happen

Answer

Global ordering across partitions is preserved

Answer

Offsets no longer need committing

Question 15

To limit duplicate processing during rebalance, what should a consumer do in `onPartitionsRevoked`?

Accepted Answer

Finish in-flight work and synchronously commit processed offsets

Answer

Reset all offsets to the beginning

Answer

Close immediately without committing

Answer

Forward in-flight messages to another topic

Question 16

In a compacted topic, why might a very late consumer never observe a key's deletion?

Accepted Answer

Tombstones are removed after `delete.retention.ms`, erasing the key from the log entirely

Answer

Tombstones are never delivered to consumers

Answer

Compaction encrypts `null`-valued messages

Answer

Tombstones reach only the first consumer group

Question 17

For a topic that should keep each entity's latest state but drop anything older than 30 days, which setting fits?

Accepted Answer

`cleanup.policy=compact,delete` with `retention.ms` of 30 days

Answer

Only `cleanup.policy=compact`

Answer

Only `cleanup.policy=delete` with no retention

Answer

`min.insync.replicas=30`

Question 18

In event sourcing, what is the source of truth?

Accepted Answer

The immutable sequence of events; current state is derived by replaying them

Answer

The latest row in a table updated in place

Answer

A Redis cache holding current state

Answer

Application logs

Question 19

Why are snapshots used in event sourcing?

Accepted Answer

To avoid replaying every event from the start when loading an aggregate

Answer

To delete old events and make the snapshot the source of truth

Answer

To encrypt events

Answer

To reorder events

Question 20

In an event store, two concurrent requests append to the same aggregate. What's the common way to prevent conflicts?

Accepted Answer

Optimistic concurrency with an expected version; the append fails if the version changed

Answer

A global lock on the entire event store

Answer

Accept both and auto-merge the events

Answer

Store both, then keep the earliest by timestamp

Question 21

In CQRS, a user places an order but doesn't see it in their order list. Cause and common fix?

Accepted Answer

The read model is eventually consistent; return a version and wait for it, or show it optimistically in the UI

Answer

The command failed and must be resent

Answer

Delete the read model and always read from the write model

Answer

Enable auto-ack in the projection consumer

Question 22

With multiple instances polling an outbox table, what ordering problem arises and how is it addressed?

Accepted Answer

Instances may publish one aggregate's events out of order; partition work by aggregate or use one leader and `FOR UPDATE SKIP LOCKED`

Answer

No problem, the database guarantees order

Answer

Events are never duplicated, so order doesn't matter

Answer

Remove the outbox and write directly to the broker

Question 23

What's the advantage of CDC (e.g. Debezium) over polling for publishing outbox events?

Accepted Answer

It reads changes from the DB transaction log (WAL or binlog) in commit order with low latency

Answer

It guarantees each event reaches consumers exactly once

Answer

It removes the outbox table and makes dual-writes safe

Answer

It works without any special database access

Question 24

What's the main downside of publishing raw internal table changes via CDC (without an outbox) to other services?

Accepted Answer

The internal DB schema becomes a public contract, so any refactor breaks consumers

Answer

CDC doesn't work on regular tables

Answer

Events are always lost

Answer

CDC only works on MongoDB

Question 25

Why is two-phase commit (XA) between a database and a broker usually avoided in microservices?

Accepted Answer

The coordinator is a blocking point, throughput drops, and many modern brokers don't support XA

Answer

2PC doesn't guarantee message order

Answer

2PC only works on NoSQL

Answer

2PC doesn't allow rollback

Question 26

How does the saga pattern maintain consistency across multiple services?

Accepted Answer

A sequence of local transactions where failures trigger compensating transactions to undo earlier steps

Answer

A single global ACID transaction across all databases

Answer

Locking all resources until the whole process ends

Answer

Retrying every step until success with no rollback

Question 27

What's the key trade-off between choreography and orchestration sagas?

Accepted Answer

Choreography is loosely coupled but hard to trace; orchestration centralizes and clarifies flow but adds a coordinator

Answer

Orchestration needs no messaging

Answer

Choreography doesn't support compensation

Answer

Orchestration only works with Kafka, choreography only with RabbitMQ

Question 28

Why must compensating transactions be idempotent and retryable?

Accepted Answer

Because a failed compensation has no further fallback and it may be delivered multiple times

Answer

Because compensations always run synchronously

Answer

Because a compensation can only ever run once

Answer

Because compensations encrypt data

Question 29

Sagas lack isolation. Which technique mitigates anomalies like dirty reads?

Accepted Answer

A semantic lock, e.g. a `PENDING` status on the record until the saga completes

Answer

Using auto-ack on every consumer

Answer

Increasing the partition count

Answer

Removing all compensating transactions

Question 30

In a saga, what is a 'pivot transaction'?

Accepted Answer

The point of no return; once it succeeds, later steps are only retried, never compensated

Answer

The first saga step, which is always compensatable

Answer

A transaction that rolls back the whole saga

Answer

A step that sends messages to the DLQ

Question 31

What problem does the inbox pattern solve alongside the outbox?

Accepted Answer

The consumer records the incoming message ID in the same transaction as its effect, so duplicates are ignored

Answer

It buffers messages in the producer before sending

Answer

It guarantees global order across services

Answer

It removes the need for a broker

Question 32

A consumer may receive `CustomerUpdated` v5 before v4. What's the safest approach?

Accepted Answer

Store each entity's version and ignore events with a lower or equal version

Answer

Apply events in arrival order

Answer

Sort by the consumer's wall-clock timestamp

Answer

Discard events and only poll the source service

Question 33

What's the cost of requiring total ordering across all messages of a Kafka topic?

Accepted Answer

You need a single partition, limiting consumption to one consumer

Answer

Kafka has total ordering by default at no cost

Answer

You must disable replication

Answer

You must set retention to zero

Question 34

If consumers are upgraded before producers, which schema compatibility mode is required?

Accepted Answer

BACKWARD: the new schema must read data written with the previous one

Answer

FORWARD: the old schema must read data written with the new one

Answer

NONE: no check is needed

Answer

Just rename the topic

Question 35

What's a safe approach for a breaking change to a widely consumed event?

Accepted Answer

Publish the new version in parallel on a new topic or type (like `OrderPlaced.v2`) and migrate consumers gradually

Answer

Change the schema in place and restart every service at once

Answer

Disable compatibility checks in the Schema Registry

Answer

Delete the old topic and recreate it with the same name

Question 36

In an immutable event log, how do you honor a personal-data deletion (GDPR) request?

Accepted Answer

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

Answer

Edit the events in place in the log

Answer

There's no way; event sourcing is incompatible with GDPR

Answer

Appending a `UserDeleted` event is enough, old data can stay

Question 37

In a strict priority queue, what risk do low-priority messages face and how is it mitigated?

Accepted Answer

Starvation; mitigated with weighted fair queuing or aging (raising priority over time)

Answer

Duplication; mitigated with idempotency

Answer

Loss of ordering; mitigated with a partition key

Answer

Weak encryption; mitigated with TLS

Question 38

An ingest API enqueues faster than the pipeline can ever process, and the backlog grows daily. What's the right strategy?

Accepted Answer

Apply backpressure at the edge (rate limits or `429`), shed low-value load, and add capacity

Answer

Grow broker memory without limit

Answer

Increase retention so messages aren't deleted

Answer

Raise prefetch on all consumers

Question 39

Why is alerting on time-based lag (seconds) usually better than offset-count lag (messages)?

Accepted Answer

Message count means different things at different traffic rates, while time lag maps directly to SLAs

Answer

Because Kafka can't compute count lag

Answer

Because time lag is always zero

Answer

Because count lag only applies to producers

Question 40

Why is an SQS FIFO queue slow when all messages share one `MessageGroupId`?

Accepted Answer

Messages in one group aren't handed out until the prior one is handled, so processing is fully serial

Answer

Because FIFO stores messages on slow disks

Answer

Because dedup waits 5 minutes per message

Answer

Because FIFO doesn't support long polling

Question 41

In which scenario is Kafka a better choice than RabbitMQ?

Accepted Answer

High-volume event streams that several independent consumers read and replay

Answer

Complex per-message routing with headers and priorities

Answer

A small task queue with per-message retries and TTL

Answer

Request/reply RPC with very low per-request latency

Question 42

In the claim-check pattern, what lifecycle challenge must be handled?

Accepted Answer

The stored payload may be deleted before consumption or linger forever; its retention must align with the queue

Answer

The payload is always stored twice

Answer

Claim-check reorders messages

Answer

The broker must decrypt the payload

Question 43

What's the difference between a domain event and an integration event?

Accepted Answer

Domain events live inside a bounded context and change freely; integration events are stable public contracts between services

Answer

Domain events are always sync and integration events always async

Answer

Integration events are only for legacy systems

Answer

There is no difference

Question 44

What's the main risk of event-carried state transfer when many services keep local copies?

Accepted Answer

Eventual consistency and replica drift if events are lost or arrive out of order

Answer

More temporal coupling because consumers call the source

Answer

Inability to scale consumers horizontally

Answer

A need for two-phase commit

Question 45

What's the main durability risk of using BullMQ or Redis Streams for critical jobs?

Accepted Answer

Redis is in-memory, and async AOF or failover to a lagging replica can lose recent jobs

Answer

Redis has no persistence at all

Answer

Redis always duplicates messages

Answer

Redis supports only one client at a time

Question 46

In a RabbitMQ cluster with classic mirrored queues, what does the `pause_minority` strategy do on a network partition?

Accepted Answer

Nodes in the minority side pause themselves to prevent split-brain and divergent writes

Answer

All nodes keep running and merge data later

Answer

The node with most messages becomes leader

Answer

The entire cluster shuts down

Question 47

When designing a consumer dedup table, what trade-off exists in how long IDs are kept?

Accepted Answer

A short window uses less storage, but redeliveries or replays older than it get reprocessed

Answer

A long window causes message loss

Answer

Retention duration has no effect

Answer

A short window guarantees message order

Question 48

A downstream service slows down and consumers keep retrying, making it worse. Which combination best protects it?

Accepted Answer

A circuit breaker, backoff with jitter, a max-attempts cap, and pausing consumption

Answer

Adding more consumers to finish faster

Answer

Removing timeouts so requests don't fail

Answer

Retrying immediately with no delay

Question 49

When replaying the whole event log to rebuild a new projection, what's the biggest danger?

Accepted Answer

Re-triggering external side effects like emails or card charges; projection handlers must be separated from them

Answer

Reordering events in the original log

Answer

Old events being deleted after replay

Answer

Kafka increasing the replication factor

Question 50

To schedule millions of delayed messages (e.g. reminders days later) on Kafka, which design is common?

Accepted Answer

Store them in a scheduler store indexed by due time and publish to the topic when due

Answer

Have the consumer `sleep` until each message is due

Answer

Set `retention.ms` to the delay duration

Answer

Use `max.poll.interval.ms` as the timer