Requests and Events

There are two ways for one service to involve another service. It can ask a question and wait for the answer (a request), or it can announce that something has happened and continue with its own work (an event). Nearly every connection between two backend services is one of these two, and the choice decides who waits, which services fail together, and which services can change without asking anyone.

Consider a parcel delivery company. At 09:14 a driver scans parcel P-58210 at the van door, and the parcel is now out for delivery. At 09:20 the customer opens the tracking page to see where the parcel is. Both moments concern the same parcel and the same status, yet they call for different kinds of communication.

The rest of this page follows that one parcel from the scan to the customer's screen and shows how to tell the two kinds apart.

Requests

A request is a message that asks another service to return something or do something, and the sender waits for the reply before it continues. When the customer opens the tracking page, the page sends GET /parcels/P-58210/status to the tracking service. The page cannot show anything useful until the answer arrives.

A request ties the two services together in time. Both must be running at the same moment, and the caller is only as fast as the service it calls. If the tracking service answers in 40 ms, the page waits 40 ms. If the tracking service takes 4 seconds, the customer watches a loading indicator for 4 seconds.

Availability multiplies along a chain of requests. Here is a simple example. The tracking page calls the tracking service, which calls the depot service, which calls the route service, and each of the three is available 99.9% of the time. The chain works only when all three work, so its availability is 0.999 x 0.999 x 0.999, or about 99.7%. A 30-day month has 43,200 minutes, so 0.1% downtime is about 43 minutes, while 0.3% is about 2 hours and 10 minutes.

• Benefit: an immediate, definite answer. The caller knows whether the work succeeded, so it can show the result or an error right away.
• Benefit: easy to follow. One call produces one reply, and a failure has one obvious place to investigate.
• Cost: shared downtime. When the called service is down, the caller fails too, unless it has a fallback.
• Cost: the sender must know every receiver. If three services must react to a scan, the scanner has to call all three, and a fourth service means changing the scanner.

Events

An event is a record that something has already happened, published so that any interested service can react to it, while the publisher does not wait for any of them. In the words of the Kafka documentation, an event records the fact that "something happened" in the world or in your business. The scan at the van door is an event: parcel P-58210 is out for delivery, and nothing that happens later can make that untrue.

Three services care about this scan. The customer texts service sends the message "Your parcel is out for delivery." The delivery estimates service recalculates the arrival window, and the analytics service counts how many parcels leave each depot per hour. The scanner needs none of their results, so it has no reason to wait for any of them.

In Kafka, a service that publishes events is a producer, and a service that reads them is a consumer. Events are stored in a named stream called a topic, which here is parcel-events. Each event has a key, a value, a timestamp, and optional headers. In this system the key is the parcel ID, and the value describes what happened:

{"type":"ParcelOutForDelivery","parcelId":"P-58210","depot":"North"}
Copy

Two properties stated in the Kafka documentation make this arrangement work. First, producers and consumers "are fully decoupled and agnostic of each other," and "producers never need to wait for consumers." Second, events "are not deleted after consumption," so a topic can have many consumers, and each one reads the same events independently.

One Scan, Three Readers

The program below publishes the scan once, and then three services read the topic, each under its own group name. Kafka keeps a separate reading position for each group name, so one service reading the event does not hide it from the others. The full program is about 45 lines; these are the two parts that matter.

try (var producer = new KafkaProducer<String, String>(producerProps)) {
    // get() waits until Kafka has stored the event, not until anyone reads it.
    RecordMetadata stored = producer.send(new ProducerRecord<>("parcel-events", "P-58210", event)).get();
    System.out.println("stored in partition " + stored.partition() + " at offset " + stored.offset());
}
Copy

// Three services read the same topic, each under its own group name.
for (String reader : List.of("customer-texts", "delivery-estimates", "analytics")) {
    // ...
    consumerProps.put("group.id", reader);
    consumerProps.put("auto.offset.reset", "earliest");
    try (var consumer = new KafkaConsumer<String, String>(consumerProps)) {
        consumer.subscribe(List.of("parcel-events"));
        // ...
    }
}
Copy

The setting auto.offset.reset=earliest tells a reader that has no saved position to start from the oldest stored event. Each event's position in the topic is its offset, a number that starts at 0. Running the program against a single Kafka 4.4 broker printed the following.

Output:

stored in partition 0 at offset 0
customer-texts read P-58210 from offset 0
delivery-estimates read P-58210 from offset 0
analytics read P-58210 from offset 0
Copy

Notice two things in the output. The producer finished as soon as Kafka stored the event, before any reader existed. The analytics service read the event after two other services had already read it, and the event was still there. To keep the output in a fixed order, the program runs the three readers one after another; in production each reader is its own process.

A fourth reader, such as a proof-of-delivery service, would need no change to the scanner. It would subscribe under a new group name and read the same events.

The Deciding Question

Ask one question about every connection: does the sender need the result before it can continue? If it does, the connection is a request. If it does not, and the sender is reporting a fact that others may act on, the connection is an event.

A second question confirms the choice: who decides what happens next? With a request, the sender decides, for example "send this text" or "calculate this route." With an event, the sender only reports what happened, and each reader decides for itself what to do about it. This difference is why requests are usually named as commands, such as SendDeliveryText, and events are named in the past tense, such as ParcelOutForDelivery.

Requests and Events in One Flow

The second row of the table matters more than it may seem at first. The scan itself starts as a request. The driver's handheld sends the scan to the tracking service and waits for confirmation, because a scan that silently disappears means a customer who never learns that the parcel is coming. Only after the tracking service has saved the new status does it publish ParcelOutForDelivery.