Mastering Message Queues: Key Interview Questions and Practical Solutions

Hello, I am Su San. To help everyone quickly locate problems and get a full picture, I have organized a directory so we can instantly understand the typical interview questions about message queues.

What are the application scenarios of message queues?

Answer: 1) Asynchronous processing 2) Traffic shaping (peak shaving) 3) Application decoupling 4) Message communication.

Asynchronous processing: Split non‑core steps from a request flow and handle them asynchronously, reducing response time and increasing throughput, e.g., sending SMS after user registration.

Traffic shaping: Use a queue to smooth traffic spikes, such as flash‑sale events, similar to how a power adapter regulates power.

Application decoupling: Two services communicate via a message system, so if one service fails the other remains unaffected, e.g., asynchronous inventory deduction after order placement.

Message communication: Built‑in efficient communication mechanisms for point‑to‑point messaging or chat rooms.

Which message‑queue frameworks are commonly used?

Answer: ActiveMQ, RabbitMQ, ZeroMQ, Kafka, MetaQ, RocketMQ, Pulsar, etc.

How to choose an MQ technology?

Answer: Compare Kafka, RocketMQ, and Pulsar on latency, throughput, reliability, transactions, replica sync strategy, multi‑tenant support, dynamic scaling, and fault recovery. See the referenced article for details.

What message models exist?

Answer: 1) Point‑to‑point model 2) Publish/subscribe model.

How to ensure MQ messages are not lost?

Answer: After understanding the middleware operation, consider three aspects:

Producer side – guarantee no loss when sending.

Broker side – ensure storage does not lose messages.

Consumer side – guarantee consumption without loss.

For detailed techniques, refer to the linked article on Kafka message loss prevention.

How to handle duplicate message consumption?

Answer: Producers may resend until an ACK is received, creating duplicates. Mature MQ servers usually deduplicate by storing processed message_id and providing idempotent send APIs. Consumers must implement idempotency themselves, e.g., checking a local database or Redis cache before processing.

How to guarantee ordered MQ messages?

Answer: Some business flows require strict ordering (e.g., order → payment → shipment). Solutions:

Global order: Use a single partition for the topic, sacrificing concurrency.

Partial order: Route messages of the same business key to the same partition (e.g., partition) and consume single‑threaded. Kafka offers the org.apache.kafka.clients.Partitioner interface for custom routing.

See the linked article for more details.

How to deal with message backlog?

Answer: Backlog occurs when consumption speed lags behind production. Solutions:

Scale out the consumer group by adding more instances.

Investigate and optimize slow consumer processing (e.g., a missing index causing a SQL query to take 500 ms instead of 10 ms).

How to ensure data consistency?

Answer: Use asynchronous messaging to decouple services. Perform local DB operations first, then send an MQ message for downstream processing. This requires transactional messages to keep the DB and MQ actions atomic.

On the consumer side, apply eventual consistency with retry mechanisms.

How are transactional messages implemented?

Answer:

Producer sends a half‑transactional message to the MQ.

MQ acknowledges receipt.

Producer executes the local transaction.

If the local transaction succeeds, send a commit; otherwise, send a rollback.

If MQ does not receive a commit/rollback within a timeout, it initiates a reverse check to the producer.

Producer queries the final transaction status.

Based on the query result, the producer sends a final commit or rollback.

How do MQ frameworks achieve high throughput?

Batch processing of messages.

Message compression to save bandwidth and storage.

Zero‑copy data transfer.

Sequential disk writes.

Page‑cache usage with asynchronous flushing to disk.

Partition design: a logical topic can have many partitions, each handled by different machines for concurrent consumption.

Why doesn’t Kafka support read/write separation?

Answer: Both producers (writes) and consumers (reads) interact with the leader replica. Separating reads to followers would break consistency (different offsets) and increase latency, which conflicts with Kafka’s design goals.

How do MQ frameworks ensure high availability?

Answer: Using Kafka as an example, a cluster consists of multiple brokers. Topics are split into partitions, each replicated across brokers. The leader handles reads and writes; followers replicate data. If a broker fails, a follower is elected as the new leader, ensuring continuous operation.

For more details, see the referenced article on common MQ interview questions.

What questions do interviewers typically ask about Kafka?

Message compression and decompression.

Partitioning strategy.

Producer idempotence and transactional support.

Broker storage mechanisms and backup.

Purpose of consumer groups.

Refer to the linked “Kafka deep dive” article for comprehensive coverage.