Backend for Frontend (BFF) pattern in Microservices - Scalability & System Analysis

Scalability Analysis - Backend for Frontend (BFF) pattern

Growth Table: Backend for Frontend (BFF) Pattern

Users	Requests per Second	BFF Instances	Microservices Load	Data Volume	Network Traffic
100	~10-50	1 small instance	Low, direct calls	Small	Low
10,000	~1,000-5,000	2-5 instances	Moderate, some caching	Moderate	Moderate
1,000,000	~100,000	20-50 instances with load balancer	High, caching + async calls	Large	High
100,000,000	~10,000,000+	100+ instances, autoscaling	Very high, sharded microservices	Very large, distributed storage	Very high, CDN + edge caching

First Bottleneck

At small scale, the BFF server CPU and memory become the first bottleneck because it handles aggregating multiple microservice calls per user request. As users grow, the database and microservices behind the BFF start to strain due to increased query volume and data processing.

Scaling Solutions

• Horizontal scaling: Add more BFF instances behind a load balancer to handle more concurrent users.
• Caching: Use caching at the BFF layer to reduce repeated calls to microservices and databases.
• Asynchronous calls: BFF can batch or parallelize microservice calls to reduce latency.
• Microservice scaling: Scale microservices independently with replicas and sharding for data-heavy services.
• CDN and edge caching: Offload static or semi-static content closer to users to reduce BFF load.
• API Gateway: Use an API gateway to route and secure requests before reaching BFF.

Back-of-Envelope Cost Analysis

Assuming 1 million users generating 100,000 requests per second:

• BFF instances: ~20-50 servers (each handles ~2000-5000 req/sec)
• Microservices: scaled to handle 100,000 QPS total, possibly with read replicas and caching
• Database: needs to support tens of thousands QPS, may require sharding and replicas
• Network bandwidth: 1 Gbps = 125 MB/s, estimate average request size to calculate total bandwidth
• Storage: depends on data retention, logs, and caching layers

Interview Tip

Start by explaining the role of BFF as a tailored backend for each frontend type. Discuss how it reduces frontend complexity by aggregating microservice calls. Then analyze scaling by identifying bottlenecks at BFF and microservices. Propose solutions like horizontal scaling, caching, and asynchronous calls. Always connect scaling steps to real user load and system limits.

Self Check

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Add read replicas and implement caching to reduce direct database load before scaling vertically or sharding.

Key Result

The BFF pattern scales by horizontally adding instances and caching to handle increased user requests, but the first bottleneck is usually the BFF server CPU and memory due to request aggregation. Scaling microservices and databases with replicas and sharding follows as traffic grows.

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