Backend interview prep

Start

Scenario-Based Messaging Interview Questions and Answers (Top 10)

Top 10 real-world messaging interview scenarios covering Kafka, RabbitMQ, IBM MQ, JMS, retries, DLQ, ordering, duplicates, performance tuning, and production troubleshooting.

Scenario-Based Messaging Interview Questions and Answers (Top 10)

Most senior Java, Spring Boot, and Solution Architect interviews focus on real production scenarios rather than theoretical concepts.

Instead of asking:

What is Kafka?

Interviewers usually ask:

Consumer lag suddenly increased to 5 million messages. What will you do?

or

Customers were charged twice after retry. How will you fix it?

This article covers some of the most common real-world messaging interview scenarios.

Enterprise Messaging Architecture

flowchart LR

Client --> ApiGateway["API Gateway"]
ApiGateway["API Gateway"] --> OrderService["Order Service"]

OrderService["Order Service"] --> Kafka

Kafka --> Inventory

Kafka --> Payment

Kafka --> Notification

Kafka --> Audit

Q1. Customers are getting duplicate payments after retries. How would you solve it?

Scenario

Payment Service failed.

Producer retried.

Consumer processed the same payment twice.

Customers were charged twice.

Solution

Never rely only on messaging guarantees.

Implement:

  • Idempotent Consumers
  • Unique Transaction ID
  • Database Constraint
  • Deduplication Table
  • Kafka Transactions (if applicable)

Solution Architecture

flowchart LR

Kafka --> Consumer

Consumer --> DuplicateCheck["Duplicate Check"]

DuplicateCheck["Duplicate Check"] --> PaymentService["Payment Service"]

DuplicateCheck["Duplicate Check"] --> IgnoreDuplicate["Ignore Duplicate"]

Interview Tip

Exactly Once Processing requires application-level idempotency.

Q2. Consumer Lag suddenly increased to millions of messages. What would you check?

Answer

Check the following:

  • Consumer CPU
  • Database latency
  • Number of partitions
  • Number of consumers
  • Network issues
  • Long-running processing
  • Broker health

Troubleshooting Flow

flowchart TD

ConsumerLag["Consumer Lag"] --> CheckConsumer["Check Consumer"]

CheckConsumer["Check Consumer"] --> CheckDatabase["Check Database"]

CheckDatabase["Check Database"] --> ScaleConsumers["Scale Consumers"]

ScaleConsumers["Scale Consumers"] --> Resolved

Best Practice

Monitor consumer lag continuously using Prometheus and Grafana.

Q3. Messages are arriving out of order. How would you fix it?

Answer

Possible reasons:

  • Multiple partitions
  • Wrong partition key
  • Multiple producers
  • Multiple retries

Solutions:

  • Use a proper partition key.
  • Send related events to the same partition.
  • Keep ordering-sensitive events together.

Ordering

flowchart LR

CustomerId["Customer ID"] --> Partition2["Partition 2"]

Partition2["Partition 2"] --> Consumer

Interview Tip

Kafka guarantees ordering only within a partition.

Q4. Payment Service is down for two hours. What happens?

Answer

If Kafka is used:

  • Producer continues publishing.
  • Kafka stores events.
  • Consumer resumes after recovery.

If RabbitMQ or IBM MQ is configured with durable queues:

  • Messages remain in queues.
  • Consumers process them later.

Recovery

flowchart LR

Producer --> Broker

Broker --> StoredMessages["Stored Messages"]

StoredMessages["Stored Messages"] --> ConsumerRecovery["Consumer Recovery"]

Benefits

  • No message loss
  • Automatic recovery

Q5. Dead Letter Queue is growing rapidly. What would you do?

Answer

Investigate:

  • Application errors
  • Invalid payload
  • Database failures
  • Schema mismatch
  • Network issues

After fixing:

  • Replay DLQ messages.

DLQ Processing

flowchart TD

Consumer --> Retry

Retry --> DLQ

DLQ --> ReplayService["Replay Service"]

Best Practice

Never delete DLQ messages without root cause analysis.

Q6. One Kafka Broker crashes during business hours. What happens?

Answer

If replication is configured:

  • Leader fails.
  • Follower becomes leader.
  • Producers reconnect.
  • Consumers continue.

No data loss occurs if ISR is healthy.

Broker Failover

flowchart LR

Leader --> Follower1["Follower 1"]

Leader --> Follower2["Follower 2"]

Leader --> Crash

Follower1["Follower 1"] --> NewLeader["New Leader"]

Interview Tip

Always configure a replication factor of at least 3 in production.

Q7. Database update succeeds but Kafka event is not published. How do you solve it?

Answer

This is the Dual Write Problem.

Solution:

Use the Outbox Pattern.

Business data and event are written in the same transaction.

Debezium publishes the event later.

Outbox

flowchart LR

Database --> Outbox

Outbox --> Debezium

Debezium --> Kafka

Benefits

  • Reliable publishing
  • No lost events
  • Transactional consistency

Q8. A banking application must process ₹5 crore transfers exactly once. What architecture would you choose?

Answer

Recommended architecture:

  • Spring Boot
  • Kafka
  • Outbox Pattern
  • Saga Pattern
  • Idempotent Consumer
  • Retry Topics
  • Dead Letter Queue
  • Monitoring
  • Audit Logging

Banking Architecture

flowchart TD

TransferApi["Transfer API"] --> SpringBoot["Spring Boot"]

SpringBoot["Spring Boot"] --> Outbox

Outbox --> Kafka

Kafka --> Fraud

Kafka --> CoreBanking["Core Banking"]

Kafka --> Notification

Best Practice

Never rely only on Kafka transactions for financial operations.

Q9. How would you troubleshoot slow message processing?

Answer

Check:

  • Consumer Lag
  • Queue Depth
  • Broker CPU
  • Database Queries
  • Thread Pool
  • Batch Size
  • GC Activity
  • Network Latency

Troubleshooting

flowchart TD

SlowConsumer["Slow Consumer"] --> Metrics

Metrics --> RootCause["Root Cause"]

RootCause["Root Cause"] --> Optimization

Optimization Ideas

  • Increase consumer concurrency.
  • Optimize database queries.
  • Tune batch size.
  • Add partitions.

Q10. What production best practices would you recommend for enterprise messaging?

Answer

Follow these recommendations:

  • Use persistent messages.
  • Implement retries with exponential backoff.
  • Configure Dead Letter Queues.
  • Design idempotent consumers.
  • Use the Outbox Pattern.
  • Use Saga for distributed transactions.
  • Monitor consumer lag.
  • Enable TLS and authentication.
  • Version event schemas.
  • Test replay and disaster recovery.

Enterprise Messaging Platform

flowchart TD

Clients --> SpringBoot["Spring Boot"]

SpringBoot["Spring Boot"] --> KafkaCluster["Kafka Cluster"]

KafkaCluster["Kafka Cluster"] --> ConsumerGroup["Consumer Group"]

ConsumerGroup["Consumer Group"] --> Database

KafkaCluster["Kafka Cluster"] --> RetryTopic["Retry Topic"]

RetryTopic["Retry Topic"] --> DLQ

DLQ --> ReplayService["Replay Service"]

KafkaCluster["Kafka Cluster"] --> Monitoring

Production Checklist

Area Best Practice
Producer Idempotent Producer
Consumer Idempotent Consumer
Retry Exponential Backoff
Failed Events DLQ
Publishing Outbox Pattern
Transactions Saga Pattern
Security TLS + Authentication
Monitoring Prometheus + Grafana
Replay Replay Service
Disaster Recovery Multi-Region Strategy

Real Banking Production Scenario

A customer transfers ₹3,00,000.

Mobile Banking

↓

Spring Boot

↓

Kafka

↓

Fraud Detection

↓

Core Banking

↓

Notification

↓

Audit

↓

Analytics

During processing:

  • Notification Service crashes.
  • Kafka retains the event.
  • Retry attempts fail.
  • Event moves to the DLQ.
  • After fixing the issue, the Replay Service republishes the event.
  • The customer receives the notification without affecting the completed transfer.

Senior Interview Tips

Interviewers commonly ask scenario-based questions such as:

  • Consumer lag increased overnight. What will you do?
  • Kafka broker crashed. What happens?
  • Duplicate messages are being processed. How do you prevent them?
  • How do you guarantee exactly-once processing?
  • Payment service is unavailable. How do you prevent message loss?
  • Why is the DLQ growing?
  • How do you replay failed messages?
  • How do you scale messaging consumers?
  • How do you maintain message ordering?
  • How do you troubleshoot slow consumers?
  • How do you monitor a messaging platform?
  • How would you design messaging for a banking system?

Strong candidates explain both the root cause and the production-ready solution, not just the technology.

Quick Revision

  • Design consumers to be idempotent to prevent duplicate processing.
  • Monitor consumer lag and queue depth continuously.
  • Use partition keys correctly to preserve ordering.
  • Configure retries and Dead Letter Queues for failure handling.
  • Use the Outbox Pattern to solve the dual-write problem.
  • Use the Saga Pattern for distributed transactions.
  • Configure replication and high availability to survive broker failures.
  • Monitor throughput, latency, retries, and broker health.
  • Build replay services for operational recovery.
  • Combine Kafka, RabbitMQ, IBM MQ, Spring Boot, monitoring, retries, and resilient design patterns to build enterprise-grade messaging systems.