Build an Event-Driven Order Service in Java (Spring Boot + Kafka)

Track: Java / Messaging Middleware

Enterprises run on asynchronous messaging — and they pay well for Java engineers who understand it. Kafka, RabbitMQ, IBM MQ, and Solace move the events that keep banks, retailers, and logistics platforms running. The fastest way to show you get event-driven architecture is to build a small service that produces and consumes events, handles failure, and doesn’t lose messages. Here’s how.

Why this project gets interviews

Event-driven, message-based systems are everywhere in enterprise Java, and most juniors have never touched them. A working producer/consumer with error handling instantly differentiates you and maps to high-value keywords: Java, Spring Boot, Kafka, event-driven architecture, microservices, messaging, RabbitMQ, IBM MQ.

Skills & keywords you’ll demonstrate

• Java + Spring Boot
• Apache Kafka producers & consumers (Spring for Apache Kafka)
• Event-driven / asynchronous architecture
• Idempotency, retries, and dead-letter handling
• Docker Compose for the broker + services

Starter repo

Clone github.com/OptimalMatch/resume-project-java-kafka-orders — a multi-module layout (order-api, order-consumer), a docker-compose with Kafka, and a milestone checklist with broker-swap notes. Build it under your own account, committing per milestone.

Build it in milestones

1. Run a broker. Start Kafka with docker-compose and confirm you can produce/consume a test message. Commit.
2. Publish events. Build an order REST endpoint that publishes an OrderPlaced event (a typed JSON payload) to a topic. Commit.
3. Consume events. Build a separate consumer that reads the topic and processes each order (log it, or reserve mock inventory). Commit.
4. Make it robust. Add retries and a dead-letter topic for messages that keep failing, and make processing idempotent (handle a duplicate event safely). Commit.
5. Observe it. Add logging/metrics so you can see throughput and failures. Commit.
6. Document the swap. In the README, explain how the same design runs on RabbitMQ or IBM MQ (exchange/queue vs topic/partition) to show breadth. Commit.

Stretch goals

• An outbox pattern so the DB write and the event publish can’t diverge.
• A second consumer group for a different reaction (e.g. notifications).
• Schema management (Avro/JSON schema) for the events.

Put it on your résumé

• “Built an event-driven order service in Java/Spring Boot with Apache Kafka — a producer publishing order events and a consumer processing them, with retries, a dead-letter topic, and idempotent handling.”
• “Containerized the broker and services with Docker Compose; documented an equivalent design on RabbitMQ/IBM MQ.”

Then run your résumé through the free ATS resume score — enterprise Java roles weight messaging and event-driven keywords heavily. The event-driven Java deep-dive goes further once you’re ready.

Frequently asked questions

Why messaging middleware for a Java résumé?
Large enterprises run on asynchronous messaging — Kafka, RabbitMQ, IBM MQ, Solace — and demand for Java engineers who understand event-driven architecture is high and well-paid. A working producer/consumer project with proper error handling stands out immediately.

Can I use RabbitMQ or IBM MQ instead of Kafka?
Yes — the architecture is the same: a producer publishes events, a consumer processes them, and you handle retries and failures. Build it with Kafka first (the most in-demand), then the starter repo notes how to swap the broker for RabbitMQ or IBM MQ to show breadth.