When Not to Use Events

On This Page

Five Questions

System One: Password Reset Emails

System Two: Moving Money Between Accounts

System Three: Location Readings from Delivery Vans

The Three Systems Side by Side

Signs of Too Many Events

Using This in an Interview

Key Takeaways

Practice Questions

Before you add a topic to a design, can you name a reader that would be worse off without it? If you cannot, the event brings every cost described in this chapter, namely delay, repeated deliveries, harder debugging, and a cluster to run, and gives nothing back.

Events are a strong tool, and that makes them easy to overuse. A design with a topic between every pair of services looks modern. Yet many of those topics replace a function call, a database transaction, or a simple job queue that would have done the same work with fewer components to run.

This page turns the chapter into a five-question test, then applies it to three short systems: one that should not use events, one that must not, and one that should.

Five Questions

Ask these in order. The first answer that points away from events usually settles the matter.

Does the sender need the result before it can continue? If it does, use a request. An event gives its publisher no result, so a sender that waits for one has built a request out of two topics.
Must several changes succeed or fail together? If they all live in one database, use a database transaction. An event cannot be taken back once another service has acted on it, so events cannot provide all-or-nothing behavior across steps.
How many readers are there, and will there be more? With one reader and no others expected, a direct call with a retry, or a plain job queue, does the same work without a cluster.
Can every reader accept delay and repeated deliveries? Kafka delivers at least once by default, and a reader may be minutes behind. A reader that cannot accept either needs extra design work, or a different mechanism.
Will anyone need the messages again after they are handled? If not, a queue is enough. If they will, a log such as a Kafka topic is worth its storage cost.

A sixth, practical question also applies: does the team already operate Kafka? A cluster is a mostly fixed cost, and a system with one small event flow carries all of it.

System One: Password Reset Emails

A user forgets a password and asks for a reset. The account service creates a one-time link, and an email sender delivers it. The site handles about 300 resets an hour, which is fewer than one every 10 seconds.

Result needed? No. The page only says "check your email."
All or nothing? No.
Readers? One, the email sender, and nothing else needs to know about resets.
Delay and repeats? A delay of a few seconds is fine. A repeat sends a second email, which is confusing but harmless if both links work until one is used.
Needed again? No. Once the email is sent, the work is finished.

Verdict: do not use events. One reader, no history, and fewer than 0.1 messages a second do not justify a topic. The account service can call the email provider with a retry, or put the job on a simple queue so that a slow provider does not block the request.

System Two: Moving Money Between Accounts

A customer moves 250 dollars from a checking account to a savings account. Both balances live in the same database. A proposed design debits checking, publishes CheckingDebited, and lets a consumer credit savings.

Result needed? Yes. The customer waits to see "transfer complete," so the customer's call is a request in either design. The next question decides how the transfer itself is made.
All or nothing? Yes. Money must never leave checking without arriving in savings.

Verdict: do not use events for the transfer itself. With the event design, there is a window, possibly minutes long if the consumer is behind, in which 250 dollars has left one account and not reached the other. If the credit fails, the debit has already happened and must be reversed by more code. A single database transaction updates both balances together, so either both changes are saved or neither is.

Events still have a place here, after the fact. Once the transaction has committed, the service can publish TransferCompleted for the statement service and the notification service. This is the pattern from the start of the chapter: a request or transaction records the change, and an event announces it.

The five-question test on three systems

System Three: Location Readings from Delivery Vans

A logistics company runs 50,000 delivery vans, and each van reports its location every 10 seconds. That is 5,000 readings a second. A live map shows every van, an arrival estimator updates delivery windows, a fuel analytics job studies routes, and a driver safety service is planned for next quarter.

Result needed? No. A van does not wait for the map to update.
All or nothing? No. Each reading stands alone.
Readers? Three now, and a fourth planned.
Delay and repeats? A map that is two seconds behind is acceptable, and a repeated reading, identified by van ID and reading time, changes nothing.
Needed again? Yes. Fuel analytics reprocesses past weeks, and the safety service will want history when it starts.

Verdict: use events, on a log. Every question points the same way. The cost to plan for is storage. At about 200 bytes a reading, 5,000 readings a second is about 1 MB a second, or about 86 GB a day. Kafka's default retention of 7 days, with the three copies of the documented durable setup, comes to about 1.8 TB, so retention for this topic is a deliberate decision rather than a default.

The Three Systems Side by Side

Question	Password reset	Money transfer	Van locations
Sender needs the result?	No	Yes	No
All or nothing?	No	Yes	No
Readers	One	One step, then announcements	Three, a fourth planned
Delay and repeats acceptable?	Yes	No	Yes
Needed again later?	No	Only the announcement	Yes
Verdict	Direct call or job queue	Database transaction, then an event	Events on a Kafka topic

Signs of Too Many Events

Existing designs often show the overuse in recognizable ways:

A request built from two topics. A service publishes PriceRequested and waits for PriceCalculated. It still waits, and it now also matches replies to questions and handles replies that never come.
A topic with exactly one reader owned by the same team. Nothing reads the events independently, so the topic adds delay and operations work in place of a function call.
Events used to keep two copies of data the same when one service could simply read from the other. Each copy may lag, and every lag is a new source of wrong answers.

Using This in an Interview

Show that you considered the alternative: "For the transfer itself I would use one database transaction, because both balances must change together. After it commits, the service publishes TransferCompleted, which the statement and notification services read."

Two follow-up questions are common:

"Why not put the password reset on Kafka too?" It has one reader, no history worth keeping, and fewer than 0.1 messages a second. A retry or a small job queue gives the same reliability without a cluster.
"When would you add events to the reset flow?" When more readers appear, for example a security service that watches for many resets on one account, and the team already runs Kafka.

Key Takeaways

A topic is worth adding only when a reader would be worse off without it.
A sender that needs the result should make a request; changes that must happen together in one database belong in one transaction.
One reader with no history to keep is usually better served by a direct call with a retry or a plain job queue.
Readers that cannot accept delay or repeated deliveries need extra design work before events suit them.
Many readers, acceptable delay, harmless repeats, and a need for history together point clearly to events on a log.
A transaction or request can record a change, and an event can then announce it, as with TransferCompleted.

This chapter decided whether a system should use events at all. Once the answer is yes, the next decisions concern where the events live: how many topics, which events share one, and what a topic actually stores. The next lesson, Topics and the Log, starts there.

Practice Questions

Try each question first, then open the answer.

1. A shopping site wants to publish CartViewed every time a user opens the cart, about 20 times a second. Only the recommendations team reads it, and they rebuild their model weekly from the past 30 days. Should this be an event on a log? Explain using the five questions.