CODEWITHSUNDEEP
design-patternsmicroservices
user2691719
user2691719

Reputation: 101

Transactional outbox pattern vs Event Sourcing

What is the exact difference between transactional outbox and event sourcing patterns? Both are competitive pattern and can be used for same purpose. Is there any example through which I can understand when to use what?

Upvotes: 7

Views: 7556

Answers (3)

Mohsen Mahmoodi
Mohsen Mahmoodi

Reputation: 357

Not only the implementations are different, but also the use cases.

To atomically update the database and send messages to a message broker, the transactional outbox is the simplest solution that can be implemented, and it should be your first choice.

Event sourcing on the other hand provides some perks like:

  1. Complete Rebuild
  2. Temporal Query
  3. Event Replay
  4. Audit Log

and adds some complexity to your service from the other hand e.g. adding CQRS support for simplifying queries that also results in eventually consistent data.

So unless there is an explicit requirement for any of the Event sourcing capabilities, for example, to support Parallel Models or Retroactive Events, etc. you should avoid adding the complexity of Event Sourcing to your service.

Better to refer to these links to understand the full list of pros, and cons of both patterns and the full scenarios when using Event Sourcing is necessary:

https://martinfowler.com/eaaDev/EventSourcing.html

https://microservices.io/patterns/data/transactional-outbox.html

https://microservices.io/patterns/data/event-sourcing.html

There is also a major difference in the lifetime of the events in the event table.

  • Event Sourcing journal is meant to be a permanent and immutable store of domain events
  • Outbox is meant to be highly ephemeral and only be a landing zone for domain events to be captured inside change events and forwarded to downstream consumers

Upvotes: 2

ddfra
ddfra

Reputation: 2565

I found these two links very useful:

https://microservices.io/patterns/data/transactional-outbox.html https://microservices.io/patterns/data/event-sourcing.html

They are both used in microservices environment to guarantee consinstency across different microservices and databases without using two-phase-commit (2PC)

The Transactional Outbox pattern allows you to have a traditional design of entities in your database and each update operation performed on the entities actually updates some rows in the database. The pattern also requires the use of an outbox table in the database so that you can have a local transaction which

  • Updates the database
  • Creates the message entry in the outbox table

A message relay is then used to read the outbox table and send messages to the broker

With the Event Sourcing pattern the database design results slightly different from a traditional design.

Think of an Account entity which has the following properties:

  • Id (string)
  • Credit (number)

Suppose you have an Account table as follows:

| Id       | Credit |
| account1 | 5      |

If you perform an update operation which adds 1 to the credit it would affect the table in the following way:

| Id       | Credit |
| account1 | 6      |

With the event sourcing pattern you don't store the Account directly in the database, instead you store the transactions happened on the accounts:

| TransactionType   | AccountId | Credit |
| Create            | account1  | 5      |
| Add               | account1  | 1      |

Since the read operations are a bit more complex with this approach (you should go along all the rows to sum and subtract the credit of each transactions to get the current credit) it is often used along with the CQRS pattern

Upvotes: 7

StepUp
StepUp

Reputation: 38134

The both patterns solves problem of how to reliably/atomically update the database and send messages/events.

So the difference lies in implementation.

Outbox pattern:

In this method, Domain Events are not written directly to a event bus. Instead of that, it is written to a table in the “outbox” role of the service that stores the event in its own database. However, the critical point here is that the transaction performed before the event and the event written to the outbox table are part of the same transaction.

Event Sourcing pattern:

Event Sourcing pattern offers to save all events into database with sequential ordered of data events. This events database called event store. Instead of updating the status of a data record, it append each change to a sequential list of events.

Upvotes: 7

Related Questions