Backend for Frontend (BFF) pattern in Microservices - System Design Exercise

Design: Backend for Frontend (BFF) Pattern Implementation

Design focuses on the BFF layer interacting with multiple microservices and clients. Out of scope are the internal designs of individual microservices and client-side implementations.

Functional Requirements

FR1: Provide tailored APIs for different client types (web, mobile, IoT).

FR2: Aggregate data from multiple microservices to reduce client complexity.

FR3: Handle client-specific logic such as authentication, caching, and response shaping.

FR4: Ensure low latency responses suitable for user-facing applications.

FR5: Support scaling independently for each client type.

Non-Functional Requirements

NFR1: Must handle 10,000 concurrent users per client type.

NFR2: API response time p99 should be under 200ms.

NFR3: Availability target of 99.9% uptime.

NFR4: Secure communication between BFF and microservices.

NFR5: Maintain separation of concerns between BFF and core microservices.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway or BFF services per client type

Authentication and Authorization service

Microservices providing business logic and data

Cache layer (e.g., Redis) for performance

Load balancers and service discovery

Design Patterns

API Gateway pattern

Aggregator pattern

Circuit Breaker for fault tolerance

Cache-Aside pattern

Authentication Token forwarding

Reference Architecture

Client (Web/Mobile/IoT)
    |
    v
+-----------------+       +-----------------+       +-----------------+
|   BFF Web       |       |   BFF Mobile    |       |   BFF IoT       |
+-----------------+       +-----------------+       +-----------------+
        |                         |                         |
        v                         v                         v
+-----------------+       +-----------------+       +-----------------+
| Auth Service    |       | Auth Service    |       | Auth Service    |
+-----------------+       +-----------------+       +-----------------+
        |                         |                         |
        +-----------+-------------+-------------+-----------+
                    |                           |
                    v                           v
           +-----------------+         +-----------------+
           | Microservice A  |         | Microservice B  |
           +-----------------+         +-----------------+
                    |                           |
                    +-------------+-------------+
                                  v
                            +------------+
                            |   Cache    |
                            +------------+

Components

BFF Web

Node.js/Express or Spring Boot

Handles web client requests, aggregates data from microservices, applies web-specific logic.

BFF Mobile

Node.js/Express or Spring Boot

Handles mobile client requests, aggregates data, optimizes payloads for mobile.

BFF IoT

Node.js/Express or Spring Boot

Handles IoT client requests, manages device-specific protocols and data shaping.

Authentication Service

OAuth2 / JWT based service

Validates and issues tokens, manages user sessions and permissions.

Microservice A

REST/gRPC microservice

Provides core business data or functionality.

Microservice B

REST/gRPC microservice

Provides additional business data or functionality.

Cache

Redis or Memcached

Stores frequently accessed data to reduce latency and load on microservices.

Request Flow

1. Client sends request to its specific BFF (e.g., web client to BFF Web).

2. BFF validates authentication token with Authentication Service.

3. BFF checks cache for requested data; if cache miss, requests data from relevant microservices.

4. BFF aggregates and transforms data as per client needs.

5. BFF sends the tailored response back to the client.

6. Cache is updated asynchronously if needed.

Database Schema

Entities: - User: id, name, email, hashed_password - Token: token_id, user_id, expiry, scopes - MicroserviceDataA: id, data_fields... - MicroserviceDataB: id, data_fields... Relationships: - User has many Tokens - MicroserviceData entities are independent, accessed via microservices Note: BFF does not store persistent data except cache and session tokens.

Scaling Discussion

Bottlenecks

BFF servers become overloaded with high concurrent client requests.

Authentication Service becomes a single point of failure.

Cache misses cause high latency due to multiple microservice calls.

Network latency between BFF and microservices increases response time.

Solutions

Scale BFF horizontally with load balancers per client type.

Use distributed authentication with token validation to reduce load.

Implement cache warming and prefetching strategies to reduce misses.

Deploy microservices and BFF in the same data center or use service mesh for optimized communication.

Interview Tips

Time: Spend 10 minutes understanding client needs and clarifying requirements, 15 minutes designing the BFF architecture and data flow, 10 minutes discussing scaling and fault tolerance, 10 minutes for Q&A and trade-offs.

Explain why BFF pattern helps tailor APIs for different clients.

Discuss separation of concerns between BFF and microservices.

Highlight caching strategies to improve latency.

Mention fault tolerance with circuit breakers and retries.

Describe scaling approaches for BFF and authentication services.

Practice

1. What is the main purpose of the Backend for Frontend (BFF) pattern in microservices architecture?

easy

A. To directly connect frontends to databases without backend logic

B. To replace all microservices with a single monolithic backend

C. To create a backend service tailored specifically for each frontend client

D. To merge all frontend code into one application

Solution

1. Step 1: Understand BFF role

   BFF acts as a specialized backend that serves the needs of a specific frontend, like mobile or web.

2. Step 2: Compare with other options

   Options B, C, and D do not describe BFF but other unrelated or incorrect architectures.

3. Final Answer:

   To create a backend service tailored specifically for each frontend client -> Option C

4. Quick Check:

   BFF = tailored backend for frontend [OK]

Hint: BFF means backend made just for one frontend [OK]

Common Mistakes:

• Thinking BFF replaces microservices
• Confusing BFF with frontend code merging
• Assuming BFF connects frontend directly to database

2. Which of the following is the correct way to describe the BFF pattern's interaction with microservices?

easy

A. BFF aggregates data from multiple microservices for frontend use

B. BFF sends frontend code to microservices

C. BFF replaces microservices with a single service

D. BFF directly modifies microservices' databases

Solution

1. Step 1: Identify BFF's role with microservices

   BFF collects and combines data from various microservices to serve frontend needs efficiently.

2. Step 2: Eliminate incorrect options

   Options A, B, and C describe incorrect or impossible interactions.

3. Final Answer:

   BFF aggregates data from multiple microservices for frontend use -> Option A

4. Quick Check:

   BFF aggregates microservices data [OK]

Hint: BFF collects data from many microservices [OK]

Common Mistakes:

• Assuming BFF changes microservices' databases
• Thinking BFF replaces microservices
• Believing BFF sends frontend code to backend

3. Consider a BFF that calls two microservices: User Service and Order Service. If User Service returns {"name": "Alice"} and Order Service returns {"orders": 3}, what will the BFF likely return to the frontend?

medium

A. {"name": "Alice"}

B. {"orders": 3}

C. {"name": "Alice", "orders": 3}

D. {"user": {"name": "Alice"}, "order": {"orders": 3}}

Solution

1. Step 1: Understand BFF data aggregation

   BFF combines data from multiple microservices into a single response for frontend simplicity.

2. Step 2: Analyze the combined response

   The best practice is to namespace responses to avoid key collisions, resulting in {"user": {"name": "Alice"}, "order": {"orders": 3}}.

3. Final Answer:

   {"user": {"name": "Alice"}, "order": {"orders": 3}} -> Option D

4. Quick Check:

   BFF namespaces microservices data to avoid conflicts [OK]

Hint: BFF namespaces microservices responses [OK]

Common Mistakes:

• Merging keys without namespaces causing conflicts
• Returning only one microservice's data
• Confusing keys or data structure

4. A developer wrote a BFF that calls multiple microservices but the frontend receives slow responses. What is the most likely cause?

medium

A. BFF is making synchronous calls to microservices one after another

B. BFF caches all responses aggressively

C. BFF uses asynchronous calls to microservices

D. BFF compresses responses before sending

Solution

1. Step 1: Identify cause of slow response

   Making synchronous calls one after another causes delays as each waits for the previous to finish.

2. Step 2: Evaluate other options

   Caching and compression usually improve speed; asynchronous calls also improve speed.

3. Final Answer:

   BFF is making synchronous calls to microservices one after another -> Option A

4. Quick Check:

   Synchronous calls cause slow BFF responses [OK]

Hint: Synchronous calls slow down BFF responses [OK]

Common Mistakes:

• Assuming caching slows down responses
• Confusing async with sync calls
• Ignoring network latency impact

5. You are designing a BFF for a mobile app and a web app. The mobile app needs minimal data for fast loading, while the web app needs detailed data. How should you design your BFFs?

hard

A. Use a single BFF that returns all data to both frontends

B. Create separate BFFs for mobile and web, each tailoring data to its frontend

C. Let frontends call microservices directly to get needed data

D. Create one BFF that returns minimal data for both frontends

Solution

1. Step 1: Understand frontend needs

   Mobile requires less data for speed; web requires more detailed data.

2. Step 2: Apply BFF pattern best practice

   Separate BFFs allow tailoring responses to each frontend's needs, improving performance and simplicity.

3. Final Answer:

   Create separate BFFs for mobile and web, each tailoring data to its frontend -> Option B

4. Quick Check:

   Separate BFFs tailor data per frontend [OK]

Hint: Use separate BFFs for different frontend needs [OK]

Common Mistakes:

• Using one BFF for all frontends ignoring needs
• Letting frontends call microservices directly
• Returning minimal data to all frontends