Erik Dvorcak

Posted on Jun 3 • Originally published at erikdvorcak.com

Monoliths That Scale: Architecting with Command and Event Buses

#architecture #eventdriven #monolith #angular

Build maintainable monoliths that enable team autonomy without microservice complexity

Most engineering teams start with a monolith. It's fast to build, easy to deploy, and straightforward to reason about—until it isn't. As features grow and teams expand, the traditional monolith becomes increasingly difficult to maintain, test, and evolve.

But what if you could design a monolith that scales with your organization, using architectural patterns typically reserved for distributed systems?

Introduction
Traditional Monolith Challenges
The Decoupled Monolith Architecture
The Command Bus Pattern
The Event Bus Pattern
Implementation in Angular
Practical Usage Examples
Testing Message-Driven Applications
Architectural Pattern Comparison
Architectural Trade-offs
Advanced Patterns & Techniques
Conclusion

Introduction

The path to microservices is often paved with monolithic regrets. Teams rush to decompose applications when faced with coupling problems, only to trade one set of challenges for another: distributed transactions, network latency, and deployment complexity.

The decoupled monolith offers an alternative approach—one that brings the modularity benefits of microservices while maintaining the operational simplicity of a single application. Central to this architecture are two critical patterns: the Command Bus and the Event Bus.

This article explores how these patterns create loosely coupled modules within a monolithic codebase, enabling your team to build maintainable applications that can evolve with changing requirements—and potentially migrate to microservices later if truly needed.

Traditional Monolith Challenges

Why Monoliths Become Problematic

Structural Problems:

Direct service calls creating tight coupling between modules
Feature boundaries blurred by shared code and direct dependencies
Circular dependencies making the codebase difficult to navigate
Single responsibility violated as components take on multiple roles

Development Challenges:

High cognitive load to understand effects of changes
Features difficult to test in isolation
Conflicting changes between teams working in shared areas
High deployment risk as changes affect the entire application

These challenges intensify as applications grow. What begins as a manageable codebase gradually transforms into a complex web of interdependencies where changes become increasingly risky and time-consuming.

The Decoupled Monolith Architecture

A decoupled monolith is a single deployable unit where internal modules communicate through well-defined messages instead of direct references. The approach maintains the operational benefits of monoliths while enabling the structural benefits of more distributed architectures.

Real-World Problem Example

Consider a common e-commerce scenario: placing an order in a traditional monolith directly calls methods on inventory, payment, notification, and analytics services, creating tight coupling. Adding new steps like fraud detection requires modifying existing code, and testing requires mocking multiple dependencies.

With a decoupled approach using command and event buses, an OrderController simply emits a ProcessOrder command and waits for a response. Independent handlers in separate modules listen for specific commands and events, enhancing modularity and making changes less risky.

Traditional vs. Decoupled Approach

Traditional tightly-coupled approach:

// order-controller-traditional.ts
class OrderController {
    constructor(
        private inventoryService: InventoryService,
        private paymentService: PaymentService,
        private notificationService: NotificationService,
        private analyticsService: AnalyticsService
    ) {}

    async placeOrder(order: Order): Promise<OrderResult> {
        // Direct service calls create tight coupling
        await this.inventoryService.reserveItems(order.items);
        const paymentResult = await this.paymentService.processPayment(order.payment);

        if (paymentResult.success) {
            await this.notificationService.sendOrderConfirmation(order);
            this.analyticsService.trackOrder(order);
            return { success: true, orderId: paymentResult.transactionId };
        } else {
            await this.inventoryService.releaseItems(order.items);
            return { success: false, error: paymentResult.error };
        }
    }
}

Decoupled approach with command and event buses:

// order-controller-decoupled.ts
class OrderController {
    constructor(private commandBus: CommandBus) {}

    async placeOrder(order: Order): Promise<OrderResult> {
        // Simply emit command and wait for response
        return this.commandBus.emitWithResponse<Order, OrderResult>(
            'ProcessOrder',
            order
        ).toPromise();
    }
}

// Independent, focused handlers in different modules
@Injectable()
class InventoryHandler {
    constructor(
        private inventoryService: InventoryService,
        private commandBus: CommandBus,
        private eventBus: EventBus
    ) {
        // Listen for the command
        this.commandBus.on<Order>('ProcessOrder')
            .subscribe(async (command) => {
                try {
                    await this.inventoryService.reserveItems(command.data.items);
                    // Pass control to the next handler
                    this.commandBus.emit({
                        type: 'ProcessPayment',
                        data: command.data,
                        requestId: command.requestId
                    });
                } catch (error) {
                    // Respond with failure if inventory check fails
                    if (command.requestId) {
                        this.commandBus.respond(command, {
                            success: false,
                            error: 'Inventory unavailable'
                        });
                    }
                }
            });

        // Listen for payment failure to release inventory
        this.eventBus.on<Order>('PaymentFailed')
            .subscribe(async (order) => {
                await this.inventoryService.releaseItems(order.items);
            });
    }
}

Core Principles

Messaging over direct calls — Components communicate by publishing and consuming messages
Module autonomy — Each feature area owns its domain logic and implementation details
Explicit contracts — Well-defined message types formalize the API between modules
Single responsibility — Each handler performs one specific task in response to a message

This architecture delivers several key benefits over traditional monoliths:

Modularity: Clear boundaries between features without infrastructure complexity of microservices

Testability: Features can be isolated and tested independently through their message interfaces

Evolution: Modules can be refined or replaced without cascading changes through the application

The Command Bus Pattern

The Command Bus serves as a mediator that routes commands (requests to perform actions) to their appropriate handlers. It implements a form of the mediator pattern to decouple command senders from the handlers that process them.

Command Pattern Fundamentals

Commands represent intents to perform an action that will change the system state. They:

Are named in imperative form: CreateUser, UpdateSettings, ProcessPayment
Typically map to a single handler that knows how to execute them
May return results directly to the sender when synchronous responses are needed
Should be immutable data structures containing all necessary information

The Command Bus itself doesn't prescribe how handlers should be implemented or how commands should be structured—it simply provides the routing mechanism between parts of your application.

Two common command interactions exist in this pattern: fire-and-forget commands and request-response commands.

The Event Bus Pattern

While the Command Bus handles direct actions, the Event Bus enables loose coupling through a publish-subscribe model. Events represent significant occurrences that have already happened within the system.

Event Pattern Fundamentals

Events represent facts that have occurred in the system. They:

Are named in past tense: UserCreated, OrderPlaced, PaymentProcessed
May have multiple subscribers, or none at all
Create an audit trail of system activities
Allow modules to react to changes without direct coupling

The Event Bus provides a way for completely separate modules to communicate without knowledge of each other—the emitter doesn't need to know who (if anyone) is listening.

This pattern enables powerful workflows where one module can emit an event that multiple other modules react to independently, each performing their specialized tasks.

Implementation in Angular

Let's examine practical implementations of both bus patterns using Angular 19+ and RxJS. These implementations leverage RxJS Subjects for message distribution and TypeScript for type safety.

CommandBus Implementation

// command-bus.service.ts
import { Injectable } from '@angular/core';
import { Observable, Subject, ReplaySubject, filter, take, timeout, throwError } from 'rxjs';

export interface CommandMessage<T = unknown> {
    type: string;
    data: T;
    requestId?: string;
}

@Injectable({ providedIn: 'root' })
export class CommandBus {
    #commandStream = new Subject<CommandMessage>();
    #pendingResponses = new Map<string, ReplaySubject<unknown>>();

    emit<T = unknown>(command: CommandMessage<T>): void {
        this.#commandStream.next(command);
    }

    emitWithResponse<T = unknown, R = unknown>(
        type: string,
        data: T,
        responseTimeoutMs = 5000
    ): Observable<R> {
        const requestId = crypto.randomUUID();
        const subject = new ReplaySubject<R>(1);
        this.#pendingResponses.set(requestId, subject as ReplaySubject<unknown>);

        subject.pipe(take(1)).subscribe({
            complete: () => this.#pendingResponses.delete(requestId)
        });

        this.emit({ type, data, requestId });

        return subject.asObservable().pipe(
            timeout({
                each: responseTimeoutMs,
                with: () => throwError(() => new Error(`Response timed out for command: ${type}`))
            })
        );
    }

    on<T = unknown>(type: string): Observable<CommandMessage<T>> {
        return this.#commandStream.pipe(
            filter((msg) => msg.type === type)
        ) as Observable<CommandMessage<T>>;
    }

    respond<R = unknown>(message: CommandMessage<unknown>, response: R): void {
        const requestId = message.requestId;
        if (!requestId) return;

        const responder = this.#pendingResponses.get(requestId);
        if (!responder) {
            console.warn(`No pending response found for requestId: ${requestId}`);
            return;
        }

        responder.next(response);
        responder.complete();
    }
}

EventBus Implementation

// event-bus.service.ts
import { Injectable } from '@angular/core';
import { Observable, Subject, filter, map } from 'rxjs';

export interface EventMessage<T = unknown> {
    type: string;
    payload: T;
}

@Injectable({ providedIn: 'root' })
export class EventBus {
    #eventStream = new Subject<EventMessage>();

    emit<T = unknown>(event: EventMessage<T>): void {
        this.#eventStream.next(event);
    }

    on<T = unknown>(type: string): Observable<T> {
        return this.#eventStream.pipe(
            filter((event) => event.type === type),
            map((event) => event.payload as T)
        );
    }
}

Implementation Highlights

TypeScript generics provide type safety across message boundaries
RxJS filtering routes messages to interested handlers
Private class fields (#) encapsulate implementation details
Early returns promote clean, flat code over nested conditionals
Timeout handling prevents hanging promises if handlers fail to respond

Practical Usage Examples

Let's explore practical examples showing how these bus implementations enable clean, decoupled interactions between application modules.

// usage-examples.ts
// Emit a simple command (fire-and-forget)
commandBus.emit({
    type: 'CreateUser',
    data: { email: 'erik@example.com' }
});

// Listen for a command
commandBus.on<{ email: string }>('CreateUser').subscribe((command) => {
    // Handle user creation logic
    userService.create(command.data.email);

    // If this command expects a response, send it
    if (command.requestId) {
        commandBus.respond(command, { id: 'new-user-123' });
    }
});

// Emit with response expectation
commandBus.emitWithResponse<{ email: string }, { id: string }>('CreateUser', { email: 'erik@example.com' }).subscribe({
    next: (res) => console.log('Created user with ID:', res.id),
    error: (err) => console.error('Failed to create user:', err)
});

// Emit an event after command completion
eventBus.emit({
    type: 'UserCreated',
    payload: {
        userId: 'new-user-123',
        email: 'erik@example.com',
        timestamp: new Date().toISOString()
    }
});

// Subscribe to events in different modules
// Module 1: Notification service
eventBus.on<{ userId: string; email: string }>('UserCreated').subscribe((data) => {
    notificationService.sendWelcomeEmail(data.email);
});

// Module 2: Analytics service
eventBus.on<{ userId: string; timestamp: string }>('UserCreated').subscribe((data) => {
    analyticsService.trackUserCreation(data.userId, data.timestamp);
});

These examples demonstrate how different parts of your application can interact without direct references to each other, using standardized message formats instead.

Testing Message-Driven Applications

One of the major benefits of a decoupled monolith is improved testability. The message-based architecture makes it easier to test components in isolation without complex mocking.

Testing Approaches

There are three key testing approaches when working with command and event buses:

1. Command Handler Testing: Test handlers in isolation by verifying they respond correctly to commands and produce expected events. Mock dependencies like services and the event bus to focus on handler logic.

2. Component Testing: When testing UI components that emit commands, mock the command bus to verify the correct messages are sent with appropriate payloads. This isolates component logic from handler implementation.

3. Integration Testing: For testing workflows that span multiple handlers, use real bus implementations but mock services. This verifies the communication flow between handlers while controlling external dependencies.

Command Handler Testing

When testing command handlers, focus on verifying they respond correctly to commands and produce expected side effects. Mock service dependencies and the event bus to isolate handler logic.

// user-command-handler.spec.ts
describe('UserCommandHandler', () => {
    let handler: UserCommandHandler;
    let mockUserService: jasmine.SpyObj<UserService>;
    let mockEventBus: jasmine.SpyObj<EventBus>;

    beforeEach(() => {
        mockUserService = jasmine.createSpyObj('UserService', ['createUser']);
        mockEventBus = jasmine.createSpyObj('EventBus', ['emit']);

        TestBed.configureTestingModule({
            providers: [
                UserCommandHandler,
                { provide: UserService, useValue: mockUserService },
                { provide: EventBus, useValue: mockEventBus }
            ]
        });

        handler = TestBed.inject(UserCommandHandler);
    });

    it('should create user and emit UserCreated event when handling CreateUser command', () => {
        // Arrange
        const createUserCommand: CommandMessage<CreateUserData> = {
            type: 'CreateUser',
            data: { email: 'test@example.com' },
            requestId: '123'
        };

        mockUserService.createUser.and.returnValue(
            Promise.resolve({
                id: 'user-123',
                email: 'test@example.com'
            })
        );

        // Act
        handler.handleCreateUser(createUserCommand);

        // Assert
        expect(mockUserService.createUser).toHaveBeenCalledWith('test@example.com');
        expect(mockEventBus.emit).toHaveBeenCalledWith({
            type: 'UserCreated',
            payload: jasmine.objectContaining({
                userId: 'user-123',
                email: 'test@example.com'
            })
        });
    });
});

Testing UI Components

For components that interact with buses, use test doubles to verify correct messages are sent. This approach isolates UI logic from the actual command handlers.

// user-registration.component.spec.ts
describe('UserRegistrationComponent', () => {
    let component: UserRegistrationComponent;
    let fixture: ComponentFixture<UserRegistrationComponent>;
    let mockCommandBus: jasmine.SpyObj<CommandBus>;

    beforeEach(async () => {
        mockCommandBus = jasmine.createSpyObj('CommandBus', ['emitWithResponse']);
        mockCommandBus.emitWithResponse.and.returnValue(of({ success: true }));

        await TestBed.configureTestingModule({
            imports: [ReactiveFormsModule],
            declarations: [UserRegistrationComponent],
            providers: [{ provide: CommandBus, useValue: mockCommandBus }]
        }).compileComponents();

        fixture = TestBed.createComponent(UserRegistrationComponent);
        component = fixture.componentInstance;
        fixture.detectChanges();
    });

    it('should emit CreateUser command when form is submitted', () => {
        // Arrange
        component.registrationForm.setValue({
            email: 'test@example.com',
            password: 'password123'
        });

        // Act
        component.submitForm();

        // Assert
        expect(mockCommandBus.emitWithResponse).toHaveBeenCalledWith('CreateUser', {
            email: 'test@example.com',
            password: 'password123'
        });
    });
});

Integration Testing

For end-to-end testing of message flows, use the actual bus implementations with mock services. This approach verifies communication between handlers while controlling external dependencies.

// order-flow.integration.spec.ts
describe('Order Processing Flow Integration', () => {
    let commandBus: CommandBus;
    let eventBus: EventBus;
    let orderHandler: OrderCommandHandler;
    let paymentHandler: PaymentCommandHandler;
    let mockInventoryService: MockInventoryService;
    let mockPaymentService: MockPaymentService;

    beforeEach(() => {
        // Use real bus implementations
        commandBus = new CommandBus();
        eventBus = new EventBus();

        // Use mock services
        mockInventoryService = new MockInventoryService();
        mockPaymentService = new MockPaymentService();

        // Create handlers with real buses but mock services
        orderHandler = new OrderCommandHandler(commandBus, eventBus, mockInventoryService);

        paymentHandler = new PaymentCommandHandler(commandBus, eventBus, mockPaymentService);

        // Initialize handlers (which sets up subscriptions)
        orderHandler.initialize();
        paymentHandler.initialize();
    });

    it('should process order through the entire flow', async () => {
        // Arrange
        const orderData = {
            items: [{ id: 'item-1', quantity: 2 }],
            payment: { cardNumber: '4111111111111111', amount: 100 }
        };

        // Spy on events
        const orderCompletedSpy = jasmine.createSpy('orderCompletedSpy');
        eventBus.on('OrderCompleted').subscribe(orderCompletedSpy);

        // Act
        const result = await commandBus.emitWithResponse('ProcessOrder', orderData).toPromise();

        // Assert
        expect(result.success).toBeTrue();
        expect(mockInventoryService.reserveCalled).toBeTrue();
        expect(mockPaymentService.processCalled).toBeTrue();
        expect(orderCompletedSpy).toHaveBeenCalled();
    });
});

Architectural Pattern Comparison

Before selecting an architectural approach, it's valuable to compare the three main patterns discussed and their suitability for different scenarios:

Feature	Traditional Monolith	Decoupled Monolith	Microservices
Deployment Complexity	✅ Low - Single deployable unit	✅ Low - Single deployable unit	❌ High - Many services with interdependencies
Internal Modularity	❌ Poor - Often becomes "big ball of mud"	✅ Strong - Well-defined boundaries via messages	✅ Strong - Complete separation between services
Team Autonomy	❌ Low - Everyone works in same codebase	⚠️ Medium - Teams own modules but share codebase	✅ High - Teams can own entire services
Operations Complexity	✅ Low - Single application to monitor	✅ Low - Single application to monitor	❌ High - Multiple services to monitor and debug
Testability	⚠️ Mixed - Often requires large test fixtures	✅ Good - Modules can be tested in isolation	⚠️ Mixed - Unit tests easy, integration tests complex
Technology Flexibility	❌ Low - Single technology stack	⚠️ Medium - Common core but flexible implementations	✅ High - Each service can use different stack
Transactional Consistency	✅ Strong - Uses database transactions	✅ Strong - Can use database transactions	⚠️ Challenging - Requires distributed patterns
Scalability	⚠️ Limited - Vertical scaling only	⚠️ Limited - Better internal scaling but still monolithic	✅ High - Services can scale independently
Implementation Cost	✅ Low - Simple to get started	⚠️ Medium - Requires disciplined design	❌ High - Requires significant infrastructure

Architectural Trade-offs

✅ Advantages

Clean modularity with explicit boundaries between features
No infrastructure overhead of distributed messaging systems
Testable architecture where modules can be isolated
Refactoring safety through well-defined message contracts
Easier migration path to microservices if needed later

❌ Considerations

Added complexity for smaller applications that don't need it
Learning curve for teams unfamiliar with message-based architectures
Debugging challenges in message-based workflows
No horizontal scaling beyond single-process capabilities
Potential message explosion without disciplined design

When To Use This Pattern

This architecture is particularly well-suited for:

Medium to large applications with distinct feature areas
Teams at risk of creating a "big ball of mud" architecture
Projects that may need microservice-like modularity in the future
Organizations that want team autonomy without distributed system complexity

Conversely, very small applications or those with minimal domain complexity may not benefit enough to justify the additional architectural patterns.

Advanced Patterns & Techniques

Once you've successfully implemented the basic command and event bus patterns, you can evolve your architecture with more advanced techniques:

CQRS (Command Query Responsibility Segregation)

Separate your reading operations from your writing operations with specialized models for each.

Use the command bus for state changes
Create a specialized query bus for data retrieval
Optimize read and write models independently

Sagas & Process Managers

Coordinate long-running processes that span multiple commands and events.

Orchestrate multi-step processes
Maintain state between steps
Handle compensating actions for failures

Decorator-Based Handler Registration

A common enhancement to the basic pattern is to add a decorator-based registration system for command handlers. This approach uses TypeScript decorators to mark methods as handlers for specific command types, improving discoverability and reducing boilerplate code.

The implementation typically involves a CommandHandler decorator that stores metadata about which methods handle which commands, and a base handler class that automatically subscribes to the relevant commands during initialization.

This pattern is especially useful in larger applications where you might have dozens of command types and handlers spread across multiple modules.

// command-handler-decorators.ts
// Command handler decorator
export function CommandHandler(commandType: string) {
    return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
        const originalMethod = descriptor.value;

        // Store metadata about this handler
        if (!Reflect.hasMetadata('handlers', target.constructor)) {
            Reflect.defineMetadata('handlers', [], target.constructor);
        }

        const handlers = Reflect.getMetadata('handlers', target.constructor);
        handlers.push({
            commandType,
            methodName: propertyKey
        });

        return descriptor;
    };
}

// Base handler class that sets up subscriptions using metadata
export abstract class BaseCommandHandlerService implements OnInit {
    constructor(protected commandBus: CommandBus) {}

    ngOnInit() {
        const handlers = Reflect.getMetadata('handlers', this.constructor) || [];

        handlers.forEach(handler => {
            this.commandBus.on(handler.commandType).subscribe(command => {
                (this as any)[handler.methodName](command);
            });
        });
    }
}

// Example usage
@Injectable({ providedIn: 'root' })
export class UserCommandHandlers extends BaseCommandHandlerService {
    constructor(
        commandBus: CommandBus,
        private userService: UserService,
        private eventBus: EventBus
    ) {
        super(commandBus);
    }

    @CommandHandler('CreateUser')
    async handleCreateUser(command: CommandMessage<CreateUserData>) {
        const user = await this.userService.createUser(command.data.email);

        this.eventBus.emit({
            type: 'UserCreated',
            payload: {
                userId: user.id,
                email: user.email
            }
        });

        // If this is a command that expects a response, send it
        if (command.requestId) {
            this.commandBus.respond(command, { success: true, userId: user.id });
        }
    }
}

Conclusion

Monoliths don't need to be rigid or unmaintainable. With command and event buses, you can structure your application in a scalable, clean, and maintainable way—gaining many benefits of microservices without the operational complexity.

This approach creates clear boundaries between modules, improves testability, and allows your system to evolve more gracefully over time. It also prepares your codebase for potential future extraction into separate services if that becomes necessary.

Consider adopting this pattern before reaching for distributed systems. You might find that a well-designed monolith meets your needs for much longer than expected, saving significant complexity and overhead.

Key Takeaways

Start simple, evolve gradually: Begin with a well-structured monolith and introduce message buses to decouple features as complexity grows
Design for testability: Message-based architectures are inherently more testable—take advantage of this for comprehensive test coverage
Be consistent with message design: Create clear conventions for command and event naming, structure, and responsibility boundaries
Consider performance implications: Message-based systems add some overhead—ensure your bus implementations are optimized for your application's needs

DEV Community