Demystifying Software Architecture: Styles/Patterns – PART 2

In my previous article, I outlined the monolithic software architecture style, its types, challenges, and trade-offs. In this article, I will explore the fascinating features of the distributed architecture style, its types, and its use cases.

Distributed Architecture

Every architecture involves trade-offs, and monolithic architecture is no exception. To overcome its challenges and align with the principles of modern architecture styles, we have adopted distributed architecture patterns. These styles excel in delivering stronger architectural characteristics, such as higher performance, improved scalability, and better availability.

We can broadly classify these patterns into five variants

Service-based architecture

This architecture is almost identical to microservices architecture, where the user interface and coarse-grained services are deployed separately, each with its own shared database. Its main advantage is flexibility—since each service (also called a domain service) and user interface is built and deployed independently, teams can make and release changes without affecting the rest of the system.

Unlike microservices or event-driven styles, this approach avoids their higher complexity and cost, making it a popular choice for many business-oriented applications.

Variants

Based on User Interfaces

1. Single Monolithic User Interface—A single user interface interacts with multiple domain services and a shared database.
2. Domain-Based User Interface—The user interface is separated by domain, with each domain having its independent services.
3. Service-Based User Interface – The user interface is grouped and deployed alongside its related domain service.

Based on Databases

• Each domain service and user interface can have its own dedicated database instead of a shared one.

Additional Features

In some implementations, an API Gateway sits at the front to handle request routing, load balancing, and rate limiting. It acts as the entry point, dispatching requests to the right domain services.

Since domain services are coarse-grained, they typically use ACID transactions (Atomicity, Consistency, Isolation, and Durability) to ensure data integrity. This involves database commits and rollbacks within the boundaries of a single domain service.

Real-world use:

• Online shopping sites: Separate services for products, orders, and payments, but one shared database.
• Banking apps: Separate services for accounts, loans, and transactions, all using the same database.
• ERP software: Separate services for sales, inventory, and HR, with a central database.
• Hospital system: Separate services for patients, billing, and pharmacy, sharing one database.
• Government portals: Separate services for tax, licenses, and citizen profiles, all connected to one database.

Best Fit For:

• Business applications requiring independent development and deployment of features.
• Teams that want flexibility without the complexity of full microservices.

Not a Good Fit For:

• Highly complex systems with fine-grained services.
• Applications requiring extreme scalability or distributed event processing.

EVENT-DRIVEN architecture

Architects and developers have designed many contemporary applications for high scalability and performance, particularly in the realms of e-commerce and financial services, utilizing event-driven architecture. They favor this approach for its agility, recoverability, availability, scalability, and resilience.

Event-driven architecture comes in two models,

• Request-based: In this model, users submit requests to the system to execute specific actions, typically directing them to a request orchestrator through a user interface. Developers can implement this within the API layer or an Enterprise Service Bus (ESB). For example, a user might retrieve/fetch order history from an e-commerce or food delivery service for a specified period, such as the past few days or months. Retrieving order history represents a data-driven, deterministic request aimed at obtaining data within defined parameters.
• Event-based: In contrast, this model involves the system responding to specific events and taking action accordingly. A prime example of this is when a customer places an order for a specific item through e-commerce platforms like Amazon, where the system initiates order processing based on the event that triggers it.

Event-driven architecture appears in two distinct topologies.

1. Broker topology: This topology provides a high level of responsiveness and dynamic control over event processing. It does not use a central event mediator to coordinate all events. Instead, the event processor components distribute the message flow among themselves in a chain-like broadcasting manager through lightweight message brokers such as RabbitMQ, ActiveMQ, or Apache Kafka. This design allows for architectural extensibility; for instance, when you place an order, the notification system receives the trigger to send an email. Although customers may not always pay attention to the email trigger, it proves beneficial if we wish to enhance features for email notifications. Succinctly, in broker topology, a producer sends events to a broker, and then the broker delivers events to many consumers, and the producer doesn’t need to bother about who consumes it.

For example, when you place an order on Amazon, you initiate the order, and an event triggers, sending event notifications to other order processing systems, including payment, shipping, and notification processors. Each processing system takes action and performs the associated tasks.

Pros

• Highly decoupled event processors
• High scalability
• High responsiveness
• High performance
• High fault tolerance

• Workflow control
• Error handling
• Recoverability
• Restart capabilities
• Data inconsistency

Real-world use:

• E-commerce: the order has been placed, and messages have been broadcasted to all the systems, like payment, inventory, and notification.
• Banking: Money has been transferred, and messages have been broadcasted to all the systems, like fraud check, SMS, and ledger.
• Food Delivery System: The order is accepted, and then messages have been broadcasted to the systems, like delivery assignment, notifications, and payment.

2. Mediator Topology: Use this topology when you need control over the workflow of event processing. In this approach, a central event mediator manages and coordinates the workflow for initiating events that require multiple event processors to work together. Succinctly, the producer triggers events, and the mediator or coordinated service decides who should do what and in what order.

Pros

• Strong workflow control
• Better error handling
• High recoverability
• Restart capabilities
• Improved data consistency

Cons

• More coupling between event processors
• Lower scalability
• Reduced performance
• Lower fault tolerance
• Complex workflow modeling

Real-world use:

• Order Processing Systems—e.g., Amazon’s order workflow where multiple services (payment, inventory, shipping) must coordinate in a defined sequence.
• Insurance Claim Processing – Claim validation, assessment, and approval require strict orchestration.
• Travel Booking Systems – Coordinating flights, hotels, and car rentals in a single booking workflow.

Best Fit For:

• Workflows requiring strict orchestration and sequencing.
• Applications needing centralized error handling and recovery.
• Complex business processes that involve multiple services working together.

Not a Good Fit For:

• High-frequency, low-latency event streams.
• Use cases where extreme scalability is required.
• Simple event flows that don’t require orchestration.

In my upcoming article, I will explore the remaining types of distributed architecture.

Stay tuned!

Happy Reading!

References

• Book: Fundamentals of Software Architecture: An Engineering Approach by Mark Richards & Neal Ford