tekBlueprint

In this article, I’ve compiled all the main architectural interaction styles and evaluated them based on their impact on connectivity, data integrity, maintenance/ownership complexity, fault tolerance, and so on. At the end, I’ll summarize everything in a comparison table to help you make your choice.

Введение

When discussing information system architecture, the focus is often on the technology stack, DBMS, and the choice of programming language or framework. However, when designing complex distributed systems, there’s another important component: the way in which services and system components interact. The way system components exchange data determines its reliability, scalability, and cost of ownership for years to come.

Over the past couple of decades, approaches have changed significantly, from monolithic applications to complex distributed landscapes hosted on cloud platforms (both on-premises and cloud-based) with hundreds or thousands of microservices. Integration patterns have also evolved: from simple, old-fashioned point-to-point interactions (P2P) to complex service meshes and event-driven topologies (EDA).

Approaches to organizing interaction

In general, I would like to divide all approaches into three categories:

1. Centralized or monolithic with a single point of integration:
   1. Enterprise Data Bus (ESB).
   2. Integration Platform as a Service (iPaaS).
2. Decentralized with synchronous interaction:
   1. Point-to-Point (P2P) interaction.
   2. API Gateway with request aggregation capability.
   3. Service Mesh.
   4. Integration Microservices (Smart Endpoints).
3. With asynchronous interaction via a message broker.
   1. Message Broker Architecture.
   2. Event-Driven Architecture (EDA).

Point-to-Point (P2P) Communication

This is probably the most obvious and simplest way to organize interactions. It’s often used as a starting point for development and is well suited for small systems. In this approach, services communicate directly: Service A knows the network address of Service B and calls it via HTTP (REST), gRPC, SOAP, and so on.

Approach

In P2P interactions, each service acts as both a client and a server. Dependencies are hard-coded: in configuration files or through service discovery mechanisms. If Service A needs data from Service B and Service C, it makes two sequential calls.

Advantages

1. Ease of getting started, as there is no need to implement complex infrastructure (message brokers, buses). This is the simplest development path.
2. High performance, as a direct call theoretically provides minimal latency due to the absence of intermediate links.
3. Transparency and ease of debugging due to the easy tracing of requests, revealing who called whom.

Disadvantages and Risks

The main problem with P2P is the exponential growth of communication complexity. If we have N services, and each service must communicate with each other, the number of connections tends to N * (N - 1) / 2.

• The consumer service is tightly coupled to the provider’s interface (contract), which means high coupling. Any change to the provider’s API requires updating all consumers. This creates a “brittle” architecture.
• Tight coupling makes it impossible to deploy services independently. You must release new versions of all related services simultaneously or implement versioning rules that support backward compatibility.
• Often, different services require similar data transformations or access rights checks, which leads to logic duplication. In a P2P architecture, this logic is duplicated in each client service.

Result

P2P is acceptable and even optimal for systems with fewer than 5-10 services, where connections are static and predictable. However, once the system starts to grow, P2P inevitably devolves into unmaintainable chaos, requiring refactoring towards centralized or asynchronous solutions.

Enterprise Data Bus

As an alternative to P2P, service-oriented architecture (SOA) using an enterprise data bus (ESB) became the dominant paradigm in the early 2000s. The idea was to centralize all integration logic.

Approach

An ESB is a ready-made solution (e.g., ServiceMix, WSO2, MuleSoft, IBM Integration Bus, Oracle Service Bus) that handles all messages between services. Services connect to the bus, not to each other. The bus handles the following functions:

• Routing (sending a message to the correct recipient).
• Transformation (converting data from the sender’s format to the recipient’s format).
• Orchestration (managing the call sequence).
• Monitoring and security.
• Ready-made connectors to external systems, such as databases, CRM, ERP, and others.

The key organizational principle is the adoption of a unified data model within the ESB. Services speak their own “dialects,” but within the bus, data is standardized. This allows new services to be added without breaking integration with existing ones.

Advantages

• Services are only aware of the bus, ensuring loose coupling. Changing a single service requires changing only the adapter on the bus.
• An ESB allows for centralized management. Security, logging, and monitoring of all data flows are all in one place. This significantly simplifies the work of the operations department.
• Transformation logic and business rules are written once and reused, eliminating duplicate functionality and saving on development costs.
• Solution providers often provide good technical support, including regular updates with fixes for bugs and known (zero-day) vulnerabilities.

Disadvantages and Risks

• This is essentially a single point of failure. If the bus fails, all integration stops. Although horizontal scaling is supported, scaling a monolithic ESB is more difficult and expensive than stateless services.
• ESB solutions are often proprietary and expensive to license and support (requiring expensive specialists), meaning high dependency on the solution provider.
• There is a risk of the provider leaving the market (for example, as a result of sanctions). A rather unpleasant situation is being left with an unsupported and unupdatable solution that requires urgent replacement. *Proprietary solutions are “black boxes” and require highly skilled specialists for modifications (if possible). Accumulating relevant experience will take years.

Conclusion

ESBs are still relevant for large, conservative corporations (banks, telecoms) with a huge number of legacy systems. However, for simple projects and cloud products, a classic, heavyweight ESB can be a problematic and inflexible solution. However, it can also significantly save development time, as it provides a fully developed and debugged ecosystem from the vendor (see ESB features above).

Message Broker Architecture

An alternative to an ESB is using message brokers, but with a different approach: “dump pipes, smart endpoints.” The logic is returned to the services, and the broker only handles delivery. In fact, I’ve often heard this approach referred to as “our” bus, which isn’t entirely accurate.

Approach

Services exchange messages via queues or topics. This is an asynchronous approach: the sender sends a message and immediately continues working without waiting for a response.

• In queues, a message is consumed by a single receiver (used for commands).
• In topics, a message is received by all subscribers (used for events).

Some examples:

• RabbitMQ, ActiveMQ Artemis – classic brokers with message routing capabilities. Excellent for tasks where delivery guarantees and complex routing logic are important.
• Apache Kafka, Redpanda, and Apache Pulsar – streaming data platforms. Essentially, these are not just brokers, but distributed logs. Ideal for Event Streaming.

Advantages

• The sender and receiver do not need to be available at the same time. The system operates even if the receiving service is unavailable (due to maintenance or an emergency).
• The broker can and does act as a buffer. If 1000 requests are received per second, and the service only processes 100, the messages will queue up, and the service will not fail.
• Consumers can be scaled horizontally by adding instances reading from the same queue.

Disadvantages and Risks

• Asynchronicity makes tracing and debugging difficult. Without third-party tools, it is impossible to directly see where a message and its contents are stuck.
• There may be issues guaranteeing strict message ordering during parallel processing.
• It is necessary to plan for messages that cannot be processed (DLQ) in advance, otherwise the queue will overflow.
• Queues with slow consumers may overflow, which can lead to the entire broker being unusable.
• In cluster deployments, it is necessary to consider the possibility of message loss in the event of a broker failure. Reliable replication mechanisms between nodes and preliminary testing on the deployment infrastructure are required. * A broker is a single point of failure, although this is rarely mentioned. Broker unavailability will block all services and can lead to data loss if the services haven’t taken this situation into account.

Summary

Message brokers are primarily used to organize interactions in solutions with a large number of services and high loads (e.g., MSA). They are a mandatory element in building robust enterprise systems to ensure reliability and fault tolerance.

Event-Driven Architecture

Event-Driven Architecture (EDA) is a further development of asynchronous communication through message brokers. While in brokers we often use messages as “commands” (do something), in EDA the primary object is the “event” (something happened).

Approach

A service doesn’t command another service to do anything. It only communicates “event X has occurred.” The main principles of EDA are:

1. Storing the system state as a sequence of events (Event Sourcing), rather than the current state in the database.
2. Separating the write and read models (CQRS). EDA fits well with CQRS, as events are consumed by readers.

Example:

• Command (Message Broker) – the order service sends a command to the warehouse service: “Ship the goods.”
• Event (EDA) – the order service publishes an event: “Order created.” The warehouse service listens to this event and decides to ship the goods. The notification service listens to the same event and sends an SMS.

Advantages

• You can add a new subscriber (for example, analytics) to the “Order created” event without touching the order service at all. This is an open/closed architecture principle and provides maximum flexibility when scaling systems.
• The system reacts to changes immediately when they occur. These aren’t real-time systems, but the response is still quite fast compared to handlers based on scheduler calls.

Disadvantages and Risks

• In EDA, data isn’t consistent at any given point in time (eventual consistency). If we change the data, the subscriber will learn about it within milliseconds or seconds. This must be taken into account, for example, when designing the user interface.
• The event format must be formalized and agreed upon. Changing the event structure is more difficult than in a synchronous API, since there may be an unknown number of consumers.

Summary

EDA is the choice for high-load, scalable systems that require flexibility. However, it requires a strong development culture and an understanding of distributed transaction principles (Saga). There’s no point in using EDA everywhere unless absolutely necessary, as the maintenance complexity is quite high.

API Gateway with Request Aggregation

When the number of microservices exceeds dozens, not only service interactions but also interactions with external clients (mobile apps, frontends) becomes a problem. A client needs to make 10 requests to 10 different services to render a page. One solution is an API Gateway.

Approach

The API Gateway is a single point of entry. It acts as a “reverse proxy” with internal routing and request aggregation logic. Key functions:

1. Routing – redirecting requests from /api/users to User Service and /api/orders to Order Service.
2. Authentication and authorization – JWT token verification occurs at the gateway. Backend services receive an already authorized request, reducing their load.
3. Aggregation – the gateway can call three services, aggregate the response into a single JSON response, and return it to the client (Mobile BFF).
4. Applying request limits to protect against DDoS and backend overload.
5. Additionally, it can perform request balancing.

GraphQL can also be included here to some extent – it can also act as a gateway for retrieving data from multiple services/microservices.

Advantages

• Hiding the complex topology of internal services. The client can communicate with only one endpoint, rather than individual services.
• Ability to centrally enforce security requirements (authentication, auditing).
• In some cases, the ability to reduce backend load by performing token verification and HTTPS traffic processing only on the gateway, passing the authorized request over HTTP.
• Allows rate limiting (throttling) and excluding unavailable services from routing (circuit breaker).

Disadvantages and Risks

• This is a single point of failure, so it must be deployed in a highly available configuration and not store state on gateways.
• Can become a performance bottleneck, as all traffic will go through the gateway. Request aggregation can further exacerbate the situation.
• Configuration difficulties may arise with a large number of services and their versioning.
• There is a certain risk of overcomplicating the gateway logic. It should remain as simple as possible and not turn into an ESB with conditions, routing, and request transformation.
• A gateway introduces additional latency, which can be critical in some cases.

Backend for Frontend (BFF)

Backend for Frontend (BFF) is an extension of the API Gateway concept. The problem with a universal gateway is that different clients have different requirements. A mobile application requires less data than the web version, while an IoT device requires a completely different format. We don’t create a single gateway, but, for example, separate services for each frontend:

• Web-BFF: For the desktop version. Returns full data, rich HTML/JSON.
• Mobile-BFF: For the mobile application. Returns truncated data, saves traffic, and aggregates calls to reduce latency.

Advantages:

• Elimination of “Fat Client” - the logic for determining which data is needed is transferred from the client to the backend. * Simplification of the client itself.
• Independence of release cycles.

Disadvantages and risks:

• Code duplication between different BFFs. This can be resolved by moving common logic to underlying services or libraries.

Summary

Compared to an ESB, an ESB connects services within the system (System-to-System). An API Gateway connects the outside world with the system (Client-to-System). An API Gateway is typically synchronous and does not handle complex business logic transformations.

An API Gateway is essential for any microservice architecture exposed to the outside world. It is the foundation for organizing a secure, predictable, and manageable API.

Integration microservices

You could say they’re the opposite of an ESB. Integration microservices are services whose sole responsibility is to facilitate interaction. They implement the “smart endpoints, dumb pipes” principle.

Approach

In this approach, integration logic is not extracted into a separate solution (like an ESB), but is encapsulated in the code of dedicated microservices. There are two main types of such services:

• Adapters (Anti-Corruption Layer) – services that wrap external or legacy systems. They translate incoming requests into a understandable internal format and back. Example: We have a legacy ERP system that operates over the SOAP protocol with cumbersome XML. We write a microservice, ErpIntegrationService, that exposes a modern REST/gRPC interface and internally converts calls to SOAP.
• Orchestrator Processors – services that manage complex transactions (Saga) or aggregate data from multiple sources without shifting this responsibility to the client or gateway.

Advantages

• Unlike an ESB, where you are limited by the bus language and tooling, an integration microservice can be written in any language. If we need to parse heavy XML, we write in Java (JAXB). If we need to work with a high-load stream, we write in Go or Rust. Development teams have full control over the technology stack.
• Integration services scale independently. If integration with an external service is slow and requires 100 instances to process a queue, while the internal integration runs on a single instance, you can allocate resources selectively. In an ESB, the entire bus monolith is scaled, which is expensive and time-consuming.
• Integration logic is often messy (error handling for third-party APIs, retries, specific protocols). Separating this logic into a separate service allows us to isolate complexity in one place without polluting the code of business services. This is an implementation of the Anti-Corruption Layer pattern from Domain-Driven Design (DDD).
• The failure of one integration service (for example, a connector to an SMS gateway) does not disrupt the entire communications infrastructure, as it would with an ESB. The rest of the system continues to function.

Disadvantages and Risks

• Without strict centralized management, teams often write the same API clients multiple times. Each team develops its own “wheel” for calling the delivery or payment service. A strong culture of developing shared libraries is necessary to reuse client and service code.
• If an integration service contains too much business logic and is tightly coupled to the data structure of other services, it becomes a bottleneck. Frequent contract changes lead to cascading changes in the integration services. You get all the disadvantages of distributed systems (network latency, difficulty debugging) and the disadvantages of a monolith (tight coupling).
• In an ESB, all monitoring is centralized and stored in one place. In an architecture with integration microservices, the call chain can be long: Client -> Gateway -> OrderService -> IntegrationService -> ExternalAPI. Debugging an error that occurred in step 4 requires an excellent distributed tracing system. Without it, troubleshooting a failure becomes a nightmare.
• An integration service that calls three external systems must ensure data integrity itself. If the second system responds with an error, changes in the first must be rolled back. This requires implementing compensating transaction patterns (Saga) in the service code, which complicates development.

Summary

Integration microservices are a convenient approach for building integration interactions and serve as a “cheap” alternative to ESB:

• Use them to implement an Anti-Corruption Layer when working with legacy systems.
• Use them to move complex orchestration logic outside of domain services.

It’s worth noting that you shouldn’t create “god services” that loop through a large number of data flows. Break integration services down by context boundaries (Bounded Context), just as you would with business services.

Infrastructure Management Layer

With the growing number of microservices, reliability issues (retries, timeouts, circuit breaking, mTLS) have become increasingly important. Implementing this logic in each service’s code is problematic and redundant. A solution at the infrastructure level is the Service Mesh.

Approach

A Service Mesh (like Istio and Linkerd) deploys a dedicated proxy container (Sidecar) next to each service.

• Data Plane – the proxies themselves, which intercept all incoming and outgoing traffic: encryption (mTLS), routing, load balancing, repeating, and observability.
• Control Plane – the management layer that tells the proxies how to behave: rule configuration, service registries, certificate management, telemetry collection.

Advantages

• The service’s programming language is irrelevant. Sidecar handles network logic (retries, security).
• Automatic metrics and tracing for all traffic without changing application code.
• Mutual authentication of services (mTLS) is configured via a single policy.
• Ability to integrate legacy services into the current infrastructure without modification.

Disadvantages and Risks

• Service Mesh is quite complex to set up and maintain. It adds an extra layer of abstraction.
• Sidecar proxies consume resources (CPU/RAM) and add latency (hops).

Bottom Line

Don’t use a Service Mesh if you have fewer than 50-100 services. It’s “heavy artillery” and will cause more problems than it’s worth at a small scale.

Integration Platform as a Service

I can’t say much about this, as I’ve never used it in practice. It seems suitable for companies whose IT landscape consists of multiple SaaS products (Salesforce, Shopify, Slack, Jira) and minimal custom development.

Approach

These are cloud platforms (Zapier, MuleSoft Anypoint, Workato, Azure Logic Apps) that provide ready-made connectors (“buttons”) for applications. Integration is configured via the UI (low-code/no-code).

Advantages

• Setup speed: days instead of months.
• No need to maintain servers (Zero Ops).
• Huge library of ready-made connectors.

Disadvantages and Risks

• Limited customization of complex business logic.
• Vendor lock-in.
• Subscription can be very expensive for large data volumes.

Summary

iPaaS is suitable for integrating SaaS and enterprise-level business processes (HR, Marketing), but is not suitable for high-load backends with custom logic.

Comparison Table

Final comparison of the main approaches based on key criteria.

Conclusion

The choice of architecture, as always, depends on the project and requirements. However, there is no requirement that one approach be used for the entire life cycle. They can and will be combined:

• Service Mesh for reliable intra-cluster communication.
• API Gateway variations for external access.
• Apache Kafka for the solution’s event engine.
• Redis/RabbitMQ/Artems for background tasks and inter-service communication.