Event-driven messaging

Services publish events, such as OrderPlaced, to a broker and others react when they are ready. It decouples producers from consumers and absorbs bursts, at the cost of eventual consistency.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

Explain what publishing an event decouples
Publish an OrderPlaced event and consume it in another service
Spot the consumer that assumes exactly-once delivery

In practice

A few lines that show Event-driven messaging doing its job.

Java

// publisher
kafka.send("orders", order.id().toString(), new OrderPlaced(order.id(), order.total()));

// consumer, in another service
@KafkaListener(topics = "orders", groupId = "invoicing")
void onOrderPlaced(OrderPlaced event) {
    if (invoices.existsByOrderId(event.orderId())) return;   // seen before: skip
    invoices.create(event);
}

The common mistake

Watch for

Assuming each event arrives exactly once. Brokers deliver at least once, so consumers must be idempotent, and a database write plus a publish must be made atomic with an outbox table.

What to know first

Your roadmap puts these before Event-driven messaging, unless you already know them.

How it stays learned

Once a session shows you understand Event-driven messaging, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

Day 3First recall, while it is fresh
Day 7Second, a week on
Day 18Last, when it has settled

Previous in the module← Retries and timeouts