Inbox pattern and outbox pattern

Actually it's very good question.

There are some differences which we should take consider. For first we got 3 approaches to delivery messages:

1. At most once - You deliver it max 1 times
2. At least once - You deliver message at least one time
3. Exactly one

Outbox pattern and inbox pattern descirbes "at least once" strategy. Let's have a look for real live example when You got API-one, message broker and API-two, so two microservices with message broker.

1. Request comes API-one
2. Your business logic starts work and probably it will be ended by something like that :

• save entity to DB and after this saving, send event to broker.

What is a problem here? If entity will be saved to DB and for some reason after that BUT BEFORE send event your api will die, API-two will be not informed about that operation, and Your data will be inconsistent.

Outbox pattern:

1. Request comes to API-one
2. Business logic is proceed
3. You come to end part and You SAVE ENTITY AND EVENT to DB in one transaction, but to DB in API-one microservice. Then some background job or whatever will look to API-one DB and check event table. It will take that event and push to broker. Then broker will eventually send You ACK of transaction and Your job will remove this event from events table.
4. Meanwhile API-two listen to broker and if message will be delivered to API-two it will proceed own business logic.

Inbox pattern

In inbox pattern situation is little bit different but very similar

1. API-one publish event to BUS
2. API-two RECIVES an event and SAVE IT TO API-two DB
3. Then some job is looking for example every 5 second into API-two DB events table and proceed every of them

To sum up - Outbox pattern - You store events into DB of API-one Inbox patter - You store events into DB of API-two

Main difference is that Outbox is for OUTCOME and Income is for processing incoming messages

Indeed, the essence of these patterns is the same. They both solve the problem of data inconsistency resulting from message send/receive errors. But they solve different halves of the problem and live on opposite sides of the message flow.

Inbox guarantees that a message will be received at least once - i.e., there will never be a situation where some work was scheduled but never performed.

Outbox guarantees that a message will be sent at least once - i.e., there will never be a situation where some work was performed but nobody was acknowledged about this.

Both of these patterns use a table in the DB in a similar way - as an intermediate buffer for messages (inbox for incoming, and outbox for outgoing), from which messages are then read out by a separate worker and processed. But they use it for different purposes.

BTW, these patterns can be used together - the same worker reads a message from the inbox, executes business logic with it, and writes a new message to the outbox.

A good article on this topic: Microservices 101: Transactional Outbox and Inbox