Software Architecture Patterns for Serverless Systems

1. Architecting for innovation: Enable change through autonomous services

Architecture is the art of defining boundaries within a system and the science of placing bulkheads along these boundaries.

Autonomous services are the cornerstone of an architecture that enables change. They own all the resources they need to continue functioning even when other services cannot. This approach creates fortified boundaries that allow teams to innovate independently, reducing lead times and increasing the pace of innovation.

Key aspects of autonomous services include:

• Command, Publish, Consume, Query (CPCQ) flow
• Asynchronous inter-service communication
• Inbound and outbound bulkheads
• Polyglot persistence and programming

By embracing autonomous services, organizations can break down monolithic systems into more manageable, flexible components that can evolve independently. This modular approach allows teams to experiment, learn, and adapt quickly without fear of breaking the entire system.

2. Event-first thinking: Trust facts and embrace eventual consistency

Events are not ephemeral messages; they are facts that represent the system contract.

Event-first thinking revolutionizes how we design systems by focusing on verbs (actions) rather than nouns (entities). This approach treats events as immutable facts stored in an event lake, providing a complete audit trail and enabling system-wide event sourcing.

Benefits of event-first thinking:

• Decouples services and allows independent evolution
• Enables reactive and evolutionary systems
• Supports idempotence and order tolerance
• Facilitates easier debugging and system analysis

By embracing eventual consistency, systems become more resilient and scalable. The event hub acts as a central nervous system, allowing services to react to changes asynchronously and maintain their own materialized views of data.

3. Turning the cloud into the database: Fight data gravity with CQRS

Data is an information system's most important asset. It must be accurate. But instead of controlling data too tightly, we want to embrace the fact that we live in an eventually consistent world.

Command Query Responsibility Segregation (CQRS) pattern helps fight data gravity by separating read and write models. This approach allows services to maintain their own optimized views of data, reducing coupling and improving performance.

Key concepts in turning the cloud into the database:

• Data life cycle architecture (Create, Use, Analyze, Archive)
• Materialized views as inbound bulkheads
• Single table design for operational performance
• Change Data Capture (CDC) for event sourcing

By distributing data across services and leveraging cloud-native storage solutions, systems can scale more effectively and adapt to changing requirements without being held back by monolithic databases.

4. Taming the presentation tier: Embrace micro frontends for flexibility

The presentation tier is a battleground. It always has been. It always will be.

Micro frontends break down monolithic user interfaces into independently deployable components, allowing teams to innovate and evolve different parts of the UI independently. This approach aligns with the backend architecture, creating full-stack autonomous teams.

Benefits of micro frontends:

• Isolates changes and reduces risk
• Maximizes potential for lazy loading
• Supports multiple frameworks and versions
• Enables offline-first and progressive web app (PWA) capabilities

By adopting micro frontends, organizations can create more responsive, resilient, and adaptable user interfaces that can evolve alongside backend services and business requirements.

5. Backend for Frontend (BFF) pattern: Optimize for specific user activities

A BFF service is responsible for a single user activity and eliminates distractions and competing demands.

The BFF pattern focuses on creating tailored backend services for specific frontend applications or user activities. This approach optimizes the API for particular use cases and reduces coupling between different parts of the system.

Characteristics of BFF services:

• Owned by the frontend team
• Implements CQRS for data access
• Provides a trilateral API (synchronous, listener, trigger)
• Supports different types of activities (Task, Search, Action, Dashboard, Reporting, Archive)

By implementing BFFs, teams can create more responsive and efficient user experiences while maintaining the flexibility to evolve different parts of the system independently.

6. External Service Gateway (ESG) pattern: Create anti-corruption layers

The ESG pattern works at the boundary of the system to provide an anti-corruption layer that encapsulates the details of interacting with other systems.

External Service Gateways act as adapters between the core system and external systems, including third-party services, legacy systems, and other subsystems. This pattern helps maintain the integrity of the core domain model and provides flexibility in integrating with various external systems.

Key aspects of ESGs:

• Ingress and egress flows
• Semantic transformation between internal and external models
• Support for various integration scenarios (e.g., webhooks, CDC, direct SQL)
• Handling of shared secrets and API keys

By implementing ESGs, organizations can more easily evolve their core systems while maintaining compatibility with external systems and protecting against external changes.

7. Control Service pattern: Orchestrate business processes with events

Control services act as mediators between collaborating boundary services. They only consume and produce events; they do not expose a synchronous interface.

The Control Service pattern enables the implementation of complex business processes and rules using event-driven orchestration. This approach centralizes control flow logic while maintaining the benefits of loose coupling between services.

Components of Control Services:

• Collect, correlate, and collate events
• Evaluate rules and conditions
• Emit higher-order events
• Implement time-based logic and expiration

Control Services support various scenarios, including business process orchestration, sagas for distributed transactions, complex event processing (CEP), and ACID 2.0 calculations for event sourcing snapshots.

8. Designing for resilience: Implement sagas and ACID 2.0 properties

To support these scenarios, we turn to an approach dubbed ACID 2.0. This new version of the classic acronym stands for Associative, Commutative, Idempotent, and Distributed.

Resilient systems must handle failures gracefully and maintain consistency in distributed environments. Two key patterns for achieving this are Sagas and ACID 2.0 properties.

Sagas:

• Break long-lived transactions into atomic steps
• Implement compensating transactions for rollback
• Use abort events to signal failures

ACID 2.0 properties:

• Associative: Result independent of grouping
• Commutative: Result independent of order
• Idempotent: Duplicate processing doesn't change result
• Distributed: Properties hold across multiple nodes

By implementing these patterns, systems can maintain consistency and recover from failures in distributed, eventually consistent environments.

9. Observability and governance: Foster a culture of robustness

Observability enables continuous governance.

Observability is crucial for understanding system behavior, identifying issues, and continuously improving performance. Coupled with automated governance practices, it creates a culture of robustness that enables teams to innovate with confidence.

Key aspects of observability and governance:

• Work metrics vs. resource metrics
• Real User Monitoring (RUM) and synthetics
• Continuous auditing and security monitoring
• TestOps for ongoing system validation

By implementing comprehensive observability and governance practices, organizations can maintain system health, security, and compliance while enabling teams to move quickly and confidently in a dynamic environment.

Last updated: August 12, 2024