Inbox Pattern
In the modern world, knowing popular event-driven architecture patterns is crucial. Today we will discuss Inbox Pattern. It helps to process incoming messages. If you are interested, read to the very end.
Don’t forget to read about “the brother” of this pattern:
- Inbox Pattern
- Outbox Pattern
You can also see how those two are very similar, but still different:
- Inbox Pattern
- Queue-Based Load Leveling Pattern
Meanwhile, let’s see what this pattern is about.
Problem
It is common for the application to receive HTTP requests (or messages).
Sometimes, the action takes more time to finish than expected. It can hit the timeout. The client may retry the action even if the first task is still alive. This causes repeated requests.
Another use case is when a request or a message is sent in a fire-and-forget manner. The app may crash when performing the task, causing data lost.
Overall, we cannot be sure that the client properly implements the retry policy when a request fails, which often leads to unpredicted behavior, messages, and data loss.
Solution
Instead of processing the request right away, the server stores it in the database.
Later, that stored request can be retrieved and processed when the service is stable.
Pros & Cons
The obvious advantages are:
- the inbox pattern ensures that a request/message was received successfully at least once
- since messages are stored, you can make sure that repeated message is processed only once
- error handling is simplified since the server may process messages in a more controlled, non-parallel way. Stored requests can be retried upon failure until completion
- stored request can be processed by a different server, releasing the load from the main one. The server that processes messages can scale separately
- it increases server availability. Requests are no longer processed right away, but when the server has enough resources
Still, there are some drawbacks:
- it leads to eventual consistency
- messages or tasks held in an inbox table require memory and storage
- this pattern might not be suitable in case an immediate response to a request is required
- the incoming request can still be lost if the server is completely down
Notice
The incoming request does not necessarily have to be stored in the database. Consider other storages like in-memory, queue, Redis, etc. The choice depends on balancing these factors:
- durability: Do I need a history of incoming messages or message is deleted after it is processed?
- scalability: Is the incoming message processed by another application? By multiple consumers?
- latency: How crucial is the time it takes to store and retrieve the message?
- resilience: Can I afford to lose all persisted inbox messages when the application goes down?
Similar patterns
This pattern is similar to the Queue-Based Load Leveling pattern. However, they solve different problems.
Get iamprovidence’s stories in your inbox
Join Medium for free to get updates from this writer.
The Inbox pattern pattern emphasizes message consistency and delivery guarantee, whereas the Queue-Based Load Leveling pattern is more about load management.
Here, instead of storing messages in the Inbox table, we can use a queue. Still, it will be an implementation detail of the server itself. However, in the Queue-Based Load Leveling pattern, the queue is a separate architecture component, that other services are aware of.
Summary
The Inbox Pattern is particularly valuable in scenarios where the delivery guarantee is important.
It works by storing heavy operations in an “inbox” table. Messages are then later processed and retried when needed.
Despite having drawbacks, the Inbox Pattern is highly useful in many scenarios, especially for applications that prioritize asynchronous handling over immediate task execution.
That’s all folks 🐷 I hope you learned something new here 🤓 Give this article a clap 👏 Support me with coffee ☕️ And do not forget to follow to learn more on event-driven architecture patterns ✅
