Event-driven does not mean decoupled

Put a message broker between two systems and the diagram gets cleaner immediately.

The producer no longer needs the consumer to be awake at the same moment. Useful.

It does not automatically make the systems independent.

They can still be welded together through schema, sequence, timing, shared meaning, replay behavior, and assumptions nobody wrote down because, again, the diagram looked clean.

Start with what the event means

An event should describe a fact the producer owns: an order was placed, inventory was adjusted, a customer profile changed.

The consumer decides what that fact means for its own behavior.

Trouble starts when an event is really a remote command with unclear ownership. UpdateCustomerEverywhere may be asynchronous, but the producer still controls consumer behavior. Add five consumers and nobody knows when the operation is complete.

Naming does not fix the design, but it exposes it. A fact can be recorded and replayed. A command expects an outcome and usually needs a clearer response path.

Time creates hidden contracts

Teams often assume an event will be processed “quickly” without defining what quickly means.

Then a customer places an order, contacts service, and finds that one system has the order while another does not. Or a price update reaches search after the storefront. Or an inventory reservation expires before fulfillment consumes it.

Eventual consistency is not a universal excuse. The business process needs an acceptable consistency window and behavior during that window.

Some interactions should remain synchronous because the caller needs a confirmed answer. Others work better as events because resilience and independent processing matter more than immediate completion.

The choice belongs to the transaction, not the architecture fashion.

Consumers own idempotency

Most delivery systems can produce duplicates. Networks fail at inconvenient points. A producer may not know whether a message was accepted. A consumer may complete work and fail before acknowledging it.

So consumers need a way to recognize work they have already completed.

That can be a stable event identifier, transaction key, version, or business invariant. The exact method depends on the operation. The requirement does not.

“Exactly once” is often a property assembled from several at-least-once components and careful application behavior. Treating it as a broker setting is optimistic.

Schema compatibility needs enforcement

Events become shared products. Producers add fields, change meanings, retire values, and sometimes remove the one property a quiet consumer depends on.

Use versioning and compatibility checks. Keep consumer contract tests. Prefer additive change where possible. Make ownership and deprecation periods explicit.

The hard part is not serializing JSON. It is changing a business fact without breaking every system that learned a slightly different interpretation of it.

Replay is a production operation

Event retention and replay can be powerful. They can also repeat emails, refunds, reservations, loyalty awards, or other side effects if the consumer was not designed for it.

Before replaying, know which consumers are idempotent, which need to be paused, and whether the current consumer code can correctly process older event versions.

Also distinguish rebuilding state from repeating actions. Those are not the same operation.

An event log is not automatically a recovery plan.

Decoupling is measured in change

The useful test is simple: can the producer change without coordinating with every consumer, and can a consumer change without the producer knowing?

If the answer is usually no, the system is still tightly coupled even if all communication is asynchronous.

Event-driven architecture can improve resilience, scale, and autonomy. I use it when ownership, contracts, time, and recovery are designed explicitly.

Otherwise the coupling is still there. Now it arrives later and at 2:00 AM.