An Event Is Not a Business Fact

“Publishing something that changed does not automatically make it a business event.”

Event-driven architecture is often described as systems communicating through events.

That sounds simple.

Something happens.

An event is published.

Other systems react.

But there is an important question hidden inside that model:

What exactly happened?

Many systems publish events whenever something changes technically:

CustomerUpdated

AccountUpdated

PaymentUpdated

RecordChanged

Those are events.

But they are not necessarily business facts.

And confusing the two creates systems that are technically event-driven while remaining deeply coupled to each other’s implementation.

Something Changed. But What?

Consider this event:

{

  "eventType": "PaymentUpdated",

  "paymentId": "PAY-12345",

  "status": "COMPLETED"

}

The event is technically valid.

Kafka delivered it.

The schema validated.

The consumer successfully deserialised it.

But what actually happened?

Was the payment approved?

Accepted by the bank?

Executed?

Booked?

Settled?

Has the customer’s balance changed?

Can the payment still be reversed?

The consumer cannot tell from the event itself.

It knows that something changed.

It doesn’t necessarily know what happened in the business.

Technical Events Describe Systems

Technical events are useful.

A cache was invalidated.

A database record changed.

A process started.

A service became unavailable.

A batch completed.

These events describe the state or operation of the technology.

There is nothing inherently wrong with them.

The problem begins when technical events are presented as business events.

Consider:

PaymentUpdated

This tells us that the producer changed its representation of a payment.

Now compare it with:

PaymentSettled

The second statement means something to the business.

It represents a fact that has occurred.

That distinction matters.

Business Facts Describe What Happened

A business fact should describe something meaningful within the business domain.

For example:

• Payment Requested

• Payment Accepted

• Funds Reserved

• Payment Rejected

• Payment Settled

• Invoice Matched

• Credit Limit Exceeded

• Customer Onboarded

These are not descriptions of database operations.

They describe outcomes and state transitions in the business.

And because they represent business meaning, consumers can make meaningful decisions based on them.

A notification service might care that a payment was rejected.

A liquidity system might care that funds were reserved.

A ledger might care that a financial event was booked.

A reconciliation process might care that settlement occurred.

Consumers subscribe to the meaning, not to the producer’s internal implementation.

A Database Change Is Not Automatically a Business Event

This is where many event-driven architectures start to leak.

A row changes.

Change Data Capture detects it.

An event is generated.

Kafka distributes it.

Consumers subscribe.

Technically, the architecture is event-driven.

Architecturally, however, the producer may simply have exposed its database to the rest of the organisation through Kafka.

Instead of coupling consumers to tables, we have coupled them to representations of table changes.

The transport changed.

The dependency did not.

A database knows that a row changed.

The business knows why it changed.

Those are different facts.

Naming Something an Event Does Not Fix It

Changing:

PaymentUpdated

into:

PaymentUpdatedEvent

does not make it a business event.

Neither does putting it on Kafka.

Neither does defining it in Avro.

Neither does storing it in an event store.

The architectural question is not whether something is technically represented as an event.

The question is:

What does this event mean to the business?

If the answer requires explaining the producer’s database, internal state machine or implementation, the event is probably leaking implementation detail.

Business Facts Need Precise Semantics

Using a business-oriented name is not enough either.

Consider:

PaymentCompleted

It sounds like a business event.

But what does completed mean?

• Completed by the payment API?

• Completed by the payment engine?

• Sent to the bank?

• Accepted by the bank?

• Booked?

• Settled?

• Irrevocably settled?

This is where events connect directly to contracts and protocols.

A business fact needs stable semantics.

Consumers need to understand what they can rely on when that fact is published.

The event name is not the contract.

The schema is not the policy.

Meaning still has to be defined.

Events Should Belong to the Domain That Owns the Fact

Ownership matters.

The system responsible for a business fact should be the authority for publishing it.

A payment service might be able to state:

Payment Accepted

But perhaps only the settlement capability can state:

Payment Settled

Those are different responsibilities.

A service should not publish facts about business state it does not own.

Otherwise the architecture creates multiple competing versions of truth.

This aligns with a central LANDA™ principle: information semantics and ownership should be understood independently of the chosen technology, and architecture should make responsibilities explicit before implementation decisions are made. 

Not Every Useful Event Is a Business Fact

There is another important distinction.

An event-driven system needs more than business facts.

Systems may also need to communicate operational or volatile state:

• Payment Engine Online

• Consumer Busy

• Settlement Window Open

• Service Offline

• Heartbeat Received

These can be extremely useful for coordination.

But they represent a different category of information.

A PaymentSettled event may need to be durable because losing it could create financial inconsistency.

A heartbeat normally does not need to be replayed three weeks later.

Only the latest state may matter.

So the architecture should not treat every event equally.

The meaning of the event should determine its delivery, durability, retention and replay requirements—not the fact that Kafka happens to carry it.

Financial Events Make This Critical

In financial systems, ambiguity around events can become expensive.

Consider the difference between:

• PaymentSubmitted

• PaymentAccepted

• PaymentExecuted

• PaymentSettled

• PaymentReturned

Those states are not interchangeable.

A consumer acting on the wrong one can produce incorrect balances, premature customer notifications, reconciliation breaks or duplicate financial actions.

LANDA™ FIN-11 therefore requires payment lifecycle states, transitions and ownership to be explicit. It also challenges duplicate messages, out-of-order updates and whether an older state can overwrite a newer one. 

That is an architectural concern.

Kafka cannot solve it.

Events Are Part of the Audit Trail

Business events can also become important evidence.

In financial systems, it may be necessary to reconstruct:

• what happened

• when it happened

• who initiated it

• which state existed before and after

• which decision was made

• which system owned that decision

Technical logs alone may not provide that evidence.

LANDA™ explicitly asks whether material actions and decisions can be reconstructed and warns against confusing technical logs with business audit evidence. 

A durable business event can contribute to that history.

But only if its semantics are stable enough to mean something later.

Business Facts Should Survive Technology Changes

There is a useful architecture test.

Imagine removing Kafka tomorrow.

Would PaymentSettled still be a meaningful business concept?

Yes.

Would FundsReserved?

Yes.

Would CustomerOnboarded?

Yes.

Now replace PostgreSQL with SQL Server.

Those facts still exist.

Replace REST with gRPC.

They still exist.

Move from microservices back to a modular monolith.

They still exist.

That’s because the facts belong to the business.

Their technical representation does not.

Event-Driven Architecture Is About More Than Transport

This brings us back to a recurring misconception.

A system is not meaningfully event-driven simply because it contains:

Producer

    ↓

Kafka

    ↓

Consumer A

Consumer B

Consumer C

That is publish/subscribe messaging.

Useful, certainly.

But architecture starts with different questions.

• What business facts should be communicated?

• Who owns them?

• What do they mean?

• Which facts must never be lost?

• Which can be duplicated?

• Which can arrive out of order?

• Which need to be replayed?

• Which represent current state rather than historical fact?

• What can consumers safely conclude when they receive one?

Those are policy questions.

Only after answering them should we decide how Kafka, RabbitMQ, Pulsar or another technology should implement the communication.

AI Will Generate Whatever Events You Ask For

AI makes this distinction even more important.

AI can generate:

• Kafka producers

• consumers

• schemas

• event classes

• serialization

• retry handlers

• topic configurations

• event stores

• integration tests

Very quickly.

Tell an AI coding agent to publish an event whenever a database entity changes and it can generate hundreds of them.

That does not mean you’ve discovered hundreds of business events.

You may simply have automated the exposure of your internal implementation.

AI makes producing events cheaper.

It does not make identifying business facts easier.

That still requires understanding the domain.

Policy vs Detail

This is another example of the same architectural principle.

The business fact is policy.

The event is a representation of that fact.

The schema defines its structure.

Kafka transports it.

A topic routes it.

A serializer encodes it.

Those are different responsibilities.

Good architecture keeps them separate.

Because technologies change.

Business facts endure.

Final Thoughts

Events are powerful because they allow systems to react to things that have happened without controlling each other directly.

But that only creates meaningful decoupling when the events themselves carry stable meaning.

Don’t publish database changes and assume you’ve created a business architecture.

Don’t add Event to a class name and assume you’ve discovered a domain event.

And don’t mistake successful message delivery for successful business communication.

Ask the harder question:

What happened in the business?

Then model that fact explicitly.

A database knows what changed.

The business knows why it mattered.

Architecture should communicate the second.

An event is not automatically a business fact.