Monolith or Event-Driven Architecture?

In a webshop, an order is received, then someone copies the data into the management system. The warehouse receives a separate notification, and billing only starts after a colleague has checked the stock. In such cases, the question is not theoretical: would a monolithic or event-driven architecture truly help? Before providing a technological answer, it's worth understanding where the information gets stuck and which manual steps still serve a real business purpose.

In many growing companies, the system itself is not the problem. The issue is that data transfer between systems, teams, and responsibilities is done by people. This is slow, error-prone, and difficult to track. The role of architecture is not to appear modern but to ensure that business processes operate predictably even when order numbers increase, product range expands, or the organization changes.

What does monolith mean in practice?

In a monolithic application, the main business functions operate within one system. For example, the same application handles orders, customers, inventory information, permissions, and billing preparation. The database, business rules, and user interface are typically closely integrated.

This is not a flaw, nor is it synonymous with an outdated approach. A well-designed monolith can be a particularly good decision for many companies. Rules are in one place, operations are simpler, there are fewer inter-system errors, and multiple steps of a process can be handled in one transaction. If an order entry requires simultaneous stock reservation, credit limit checking, and task creation, a monolith can provide clear operation.

The problem begins when the system no longer serves clearly separated business areas, and every new requirement is added to the same place. A small change in billing can unexpectedly affect the warehouse process. A development release may require deploying the entire application. If multiple teams work on the same codebase, coordination alone can slow down changes.

However, this is also a matter of design and organization. Not every large monolith is unmanageable, and not every smaller system deserves immediate dismantling.

How does event-driven architecture work?

In event-driven operation, a business event sends a signal to other affected systems. Such an event can be "order placed," "goods received," "manufacturing operation completed," or "invoice paid." The system that creates the event does not necessarily perform all subsequent tasks. Instead, it publishes what happened, and other systems respond within their own responsibilities.

Let's take a simple example. The webshop records that a new order has arrived. The inventory management system reserves the goods, the logistics system creates the picking task, the customer communication solution sends a confirmation, and reporting updates daily sales data. The webshop does not need to know every detailed rule.

This is particularly advantageous when multiple systems with different life cycles need to respond to the same business change. Manufacturing, warehousing, transportation, customer service, and finance may not work at the same speed or within the same application. Events help ensure that information does not start via email, spreadsheet, or phone.

However, event-driven architecture does not mean that everything updates immediately and under all circumstances. For some processes, it is acceptable that the order status appears in the warehouse view a few seconds later. In other cases, such as stock reservation or payment approval, stricter rules are needed. The two situations should not be treated the same.

Monolithic or event-driven architecture: not a true yes-no question

The two approaches are often treated as a false choice. As if a company could only have one large application or many services connected by events. In reality, most well-functioning environments are hybrid.

A central management or production system can remain monolithic while passing specific business events to other systems. This way, core processes operate in one place, in a controlled manner, but the webshop, carrier connection, customer notification, or data platform does not become captive to the central system's internal logic.

This is generally a safer development path than suddenly breaking up an entire system. If a company currently has a reliable but difficult-to-integrate system, the first step is to clarify which business events matter. Not data changes in a technical sense, but real business states: the production batch is completed, the package is handed over to the courier, an approval deadline has expired, a discrepancy has occurred in the inventory.

When is it justified to keep the monolith?

The monolith is advantageous if processes are closely linked, changes are rare, and the business does not need multiple independently evolving systems. In an internal management application used by few, well-defined roles, the lower operational burden is often more valuable than the promise of technological separation.

It may also be justified if the organization lacks the capacity to operate complex integrations. Handling events requires more than just introducing a message broker. Monitoring, logging, permission management, retry strategy, fault tolerance, and clear responsibility are needed. If a process fails, it must be known who gets notified, how the data is corrected, and what happens to dependent processes.

The monolith is not good because we call it simple, but because its boundaries are clear. Functions, data, and responsibilities do not mix uncontrollably.

When does event-driven operation bring business value?

The event-driven approach is strong when there is a lot of handover and repetitive coordination in the company. A typical sign is when multiple teams need to know about the same change, but this is currently handled manually. For example, procurement sends a separate email to the warehouse, the warehouse maintains a separate spreadsheet, and sales only later learns that an order cannot be fulfilled.

It is also useful where new related systems are expected. A company may only use a webshop and ERP today, but next year it may introduce a customer portal, automated label printing, carrier integration, or a management data platform. If the fundamental business events are well-defined, new capabilities can be added with less risk.

The most important advantage is not technological flexibility. It is that it becomes visible what happened in a process. A well-designed event chain allows tracking when an order was received, when stock reservation occurred, why fulfillment stopped, and in which system a discrepancy occurred. This provides better decision-making for management and less burden on those employees who today try to piece together the story from memory.

The hidden cost: complexity and responsibility

Event-driven architecture is not free flexibility. A system may delay, an event may arrive twice, the recipient may be temporarily unavailable, or a business rule may change during the process. These must be planned for in advance.

For example, it is not enough to say that stock should decrease when an order is placed. It must be defined what happens if payment is declined, if the order is modified, if the warehouse finds less goods, or if the same event is processed twice due to a technical error. Such questions are actually business control questions. Technology can only handle them correctly if the process owner and rules are clear.

That's why it's dangerous to decide based solely on development trends. In a system broken up too early, the previous internal complexity simply transfers to the connections between systems. The error will no longer be within one application but between two or three teams, data sources, and responsibility boundaries.

What questions should be asked first?

Before choosing an architecture, it is worth following a specific process from the triggering event to closure. Who records the data? Where is the same information recreated? Which step requires email, phone, or a separate spreadsheet? Who can say why a case stopped? And which rule is known only by one experienced employee?

If the answers indicate few systems and strongly interconnected processes, an organized monolith may be the right foundation. If many separate systems, frequent handovers, and increasing integration needs appear, connecting along events may become justified. Between the two, there are many transitional, gradually implementable solutions.

A good architecture is not valuable because of the number of services it consists of. It is valuable because the path of an order, manufacturing task, or invoice exists in a verifiable process, not in people's minds. If this can be clarified, the technological decision will no longer be a matter of belief but a directed business development.