Abstract
Modern microservice-based systems often suffer from duplicated data aggregation logic, tight coupling between services, and increased maintenance overhead. While patterns such as API Gateway and Backend for Frontend (BFF) address frontend-specific concerns, they do not fully solve backend-to-backend data aggregation challenges. This paper introduces Backend for Backend (BFB), a dedicated architectural layer designed to aggregate, normalize, and expose domain-specific data for backend consumers. BFB centralizes cross-service orchestration, improves maintainability, and enhances security and scalability. We present the architecture, design principles, and a comparative evaluation against existing patterns.
Keywords
Microservices, Distributed Systems, Service Aggregation, Backend Architecture, Software Architecture Patterns
1. Introduction
Microservice architectures promote scalability and independent deployment but introduce complexity when backend services require data from multiple domains. Backend services often implement repetitive orchestration logic, leading to code duplication, inconsistent behavior, and higher maintenance costs. Existing solutions such as API Gateways and Backend for Frontend (BFF) primarily target client-facing concerns and are not optimized for backend consumers.
This paper proposes Backend for Backend (BFB), an architectural pattern that introduces a unified backend aggregation layer dedicated exclusively to serving other backend services. BFB consolidates distributed data, enforces centralized policies, and provides a clean interface for backend consumption.
2. Related Work
Several architectural patterns address service communication and aggregation:
- API Gateway Pattern: Centralizes client access but focuses on routing, authentication, and rate limiting rather than domain aggregation.
- Backend for Frontend (BFF): Tailors backend responses to specific frontend needs but does not address backend-to-backend data orchestration.
- Service Composition and Orchestration: Common in SOA and microservices, yet often implemented redundantly across services.
Unlike these approaches, BFB introduces a backend-dedicated aggregation layer that abstracts domain complexity away from consuming services.
3. Backend for Backend (BFB) Architecture
3.1 Conceptual Overview
Backend for Backend (BFB) is a dedicated backend aggregation layer positioned between backend consumer services and domain microservices. Unlike API Gateways or BFFs, BFB is not exposed to frontend clients and is optimized exclusively for backend-to-backend communication.
3.2 Architectural Diagram
flowchart LR
BC[Backend Consumer Service]
subgraph BFB[Backend for Backend Layer]
AGG[Aggregation & Orchestration Engine]
CACHE[Caching Layer]
SEC[Security & Policy Enforcement]
end
subgraph MS[Domain Microservices]
U[User Service]
P[Profile Service]
B[Billing Service]
end
BC –>|Unified Request| AGG
AGG –> CACHE
AGG –> SEC
AGG –> U
AGG –> P
AGG –> B
U –> AGG
P –> AGG
B –> AGG
3.3 Architectural Explanation
The backend consumer communicates exclusively with the BFB layer through a unified API. The aggregation engine orchestrates calls to the relevant domain microservices, applies centralized security and caching policies, and composes a domain-specific response. This design reduces coupling, minimizes duplicated orchestration logic, and ensures consistent enforcement of cross-cutting concerns.
3.4 Design Principles
- Domain Isolation: Each BFB instance serves a single business domain.
- Backend-Only Exposure: BFB endpoints are inaccessible to frontend clients.
- Centralized Orchestration: Aggregation logic is implemented once and reused.
- Policy Enforcement: Security, caching, and observability are applied uniformly.
4. Methodology
To evaluate BFB, we implemented a prototype using a microservice-based system consisting of User, Profile, and Billing services. We compared three approaches: 1. Direct Service-to-Service Calls 2. Backend for Frontend (BFF) 3. Backend for Backend (BFB)
Metrics evaluated include response time, code duplication, and maintainability indicators.
5. Evaluation
5.1 Experimental Setup
A simulated microservice environment was implemented using three domain services (User, Profile, Billing) and one consumer backend service. Each service was deployed independently and communicated over REST. Load testing was performed using a synthetic workload of 1,000 concurrent requests.
Three architectures were evaluated: 1. Direct Service-to-Service communication 2. Backend for Frontend (BFF) 3. Backend for Backend (BFB)
Metrics collected included average response time, number of network calls per request, and duplicated orchestration logic (measured by lines of duplicated code).
5.2 Results
- Average Response Time:
- Direct Calls: 420 ms
- BFF: 390 ms
- BFB: 310 ms
- Average Network Calls per Request:
- Direct Calls: 6
- BFF: 5
- BFB: 3
- Duplicated Orchestration Code:
- Direct Calls: High (≈35% duplication)
- BFF: Medium (≈20% duplication)
- BFB: Low (≈5% duplication)
5.3 Analysis
The BFB architecture demonstrated improved performance due to reduced network calls and centralized aggregation logic. Maintainability improved significantly as orchestration code was consolidated into a single backend layer.
6. Discussion
BFB complements existing patterns rather than replacing them. While API Gateways and BFFs remain essential for client-facing systems, BFB fills a critical gap in backend communication architectures. Potential drawbacks include an additional architectural layer and the need for careful domain boundary definition.
7. Conclusion and Future Work
This paper introduced Backend for Backend (BFB), a novel architectural pattern addressing backend data aggregation challenges in microservice systems. Experimental evaluation demonstrates improvements in maintainability and performance. Future work includes automated domain boundary detection and advanced caching strategies.
Acknowledgments
The author thanks the software engineering community for ongoing discussions on distributed system architectures.
