Hey there!

Summary of this email:

• The Inbox and Outbox patterns can be over-engineering (+ course published on Codely Pro)

⏱️ Estimated reading time: 1 quick minute.

📬 The Inbox and Outbox patterns can be over-engineering

The inbox and outbox patterns are two patterns that ensure a message has been delivered or sent. To analyze them, let's imagine a user registration use case:

📤 The Outbox pattern

The outbox pattern is the pattern that ensures a message is always delivered.

Once a user has registered (insert into the database), we want to publish the user registered event (in RabbitMQ, for example).

But something that can happen is that Rabbit goes down. At that point we can choose to:

• 💥 Roll back the user insert and return a 500 error.
• 🥺 Accept that we've lost the event.
• 📤 Apply the outbox pattern.

Obviously we don't like the first two options, so we can go with the 3rd. This means that instead of publishing to RabbitMQ at that moment, we insert the event into our own table.

Then we'll have another process that reads from that table and publishes to Rabbit. This way we ensure that use cases always work correctly.

📤 The Inbox pattern

The inbox pattern is the pattern that ensures a message is always read.

In a subscriber, we can listen for the user registered event to send a welcome email.

But something that can happen is that the email service is down, and because of that we lose the event, or that the queue gets saturated and Rabbit ends up crashing because of it.

If we apply the inbox pattern, what we do is save the message to a table in our database once it's consumed. This way, if many messages pile up, it's our database that fills up instead of Rabbit.

Then we'll have a process that reads from that table and executes the corresponding subscriber.

These 2 patterns are very powerful since they decouple us from the messaging system (they can also help us decouple from email services, notifications...). Additionally, the inbox pattern can help us avoid consuming duplicate messages.

On the other hand, adding these systems "just in case" can cause various problems. We've added new levels of indirection, shifted load to another system (from Rabbit to the DB), added new processes to consume from these tables... Textbook over-engineering.

We explain all of this in the course we just published about these patterns. Now available for Codely Pro Premium. 😊

And since you've made it to this part of the newsletter, here's the joke of the week, which I know you were waiting for:

> Why is the God Object depressed? Because it's been given too many responsibilities. 😂 😂 😂 Joke sent by Esti Alvarez, thanks a lot! 😊 - If you want to send us your tech joke, post it on Twitter mentioning us.

Cheers!