Decoupling in Software Architecture Moves Complexity

What happens when someone clicks the Place Order button?

To the end user, it is pretty simple. It is a button click. But in a large system, there can be a lot going on behind that button. We have to save the order, record the payment, charge the customer’s credit card, reserve inventory, send a confirmation email, and maybe record loyalty points. There may also be analytics, recommendations, or other processes that react to the order.

Because there are so many things happening, there are also a lot of things that can go wrong.

We are often told that decoupling is great. Use abstractions. Use dependency injection. Replace direct calls with messages and queues. Use publish subscribe and event driven architecture.

All of those things can be useful, but they are not goals. More importantly, they are not free.

Every step you take away from an in memory method call adds a new kind of complexity and a new cost. You might gain independent deployability, extensibility, scalability, or different availability characteristics. But you are introducing something else that you now have to understand, operate, and debug.

YouTube…