Load Balancers vs API Gateways vs BFFs

Don't let the terms confuse you...

While talking to fellow developers over the years, I’ve noticed one specific point multiple times.

Developers tend to get confused between Load Balancers, API Gateways, and BFFs.

Let’s clarify the confusion once and for all.

Load Balancers

When you arrive at a hotel, you're often greeted by a receptionist who checks your documents, enters your information into their system, and guides you to your room.

If the hotel is busy, they may have multiple receptionists to handle the influx of guests.

Load balancers perform a similar function for your application.

They act as the first point of contact for incoming requests and distribute them across multiple servers to ensure efficient processing and optimal performance.

You can play around with the diagram on Eraser.io

Just like a hotel receptionist directing guests to available rooms, a load balancer routes incoming requests to servers that have the capacity to handle them. This helps prevent any single server from becoming overwhelmed and ensures that things keep chugging along nicely.

In addition to distributing the workload, load balancers also play a crucial role in maintaining the availability of your application.

If one server goes down or becomes unresponsive, the load balancer automatically redirects the requests to another available server. This failover mechanism helps minimize downtime and ensures that your application remains accessible to users.

API Gateway

Imagine a scenario where a company is conducting interviews for various positions, such as Tech Architect, Engineering Manager, and Software Engineer.

Each position has a dedicated interview panel located in separate rooms.

To ensure a smooth interview process, the company assigns a coordinator who greets the candidates, checks their profiles, and directs them to the appropriate panel.

This coordinator acts as a single point of contact for the candidates, eliminating the need for them to search for the correct room on their own.

In a software system, an API Gateway plays a role similar to that of the interview coordinator. It acts as the entry point for client requests and routes them to the appropriate backend services based on the request's characteristics, such as the URL path, HTTP method, or headers.

You can play around with the diagram on Eraser.io

API Gateways also do a lot of other things:

1. Authentication and Authorization: API Gateways can verify the identity of clients and ensure that they have the necessary permissions to access the requested resources. This can be done through techniques like API keys, OAuth tokens, or JSON Web Tokens (JWT).

2. Rate Limiting: To protect backend services from being overwhelmed by a high volume of requests, API Gateways can enforce rate limits. They can restrict the number of requests a client can make within a specific time window, preventing abuse and ensuring fair usage of resources.

3. Logging and Monitoring: API Gateways can log incoming requests and their corresponding responses, providing valuable insights into system usage and performance. These logs can be used for debugging, auditing, and generating analytics.

4. Caching: API Gateways can cache responses from backend services to improve performance and reduce the load on the underlying infrastructure. When a client requests a resource that has been previously cached, the API Gateway can serve the cached response instead of forwarding the request to the backend service.

Fun Fact: Layer 7 Load Balancers as API Gateways

Interestingly, Layer 7 Load Balancers, which operate at the application layer of the OSI model, can also function as API Gateways.

They can perform request routing based on the content of the HTTP request, such as the URL path or headers, making them suitable for API Gateway responsibilities.

However, dedicated API Gateway solutions often provide additional features and flexibility compared to Layer 7 Load Balancers, such as more granular request routing rules, request transformation, and integration with other services like authentication providers or caching systems.

Backends for Frontend

Let's extend our interview example to illustrate the Backends for Frontends (BFF) pattern.

In this scenario, each position (Tech Architect, Engineering Manager, Software Engineer) has specific rounds of discussions. While some rounds may be unique to a particular position, others can be common across all positions, such as the Director Round.

The BFF pattern acts as a coordinator, managing the specific rounds for each type of interview. It provides a tailored backend for each frontend, catering to their specific requirements.

You can play around with the diagram on Eraser.io

In system terms, the BFF pattern is a component that handles the varying requirements of different devices or clients. For example:

• A BFF for web applications can handle the specific needs of web-based frontends, such as optimizing data payloads and managing browser-specific concerns.

• A BFF for mobile devices can cater to the unique requirements of mobile apps, such as handling device-specific APIs and optimizing network usage.

• A BFF for external applications can provide a tailored interface for third-party integrations, ensuring compatibility and security.

👉 So - have you used Load Balancers, API Gateways, and BFFs before?

---

Shoutout

Here are some interesting articles I’ve read recently:

• Senior Developers understand Composition Over Inheritance by

  Raul Junco

• Fancy or Fragile? How to Hit the Sweet Spot (Over-engineering vs Under-engineering) by

  Akos

• Serving Video by

  Franco Fernando

• Why you should attend a software engineering conference by

  Fran Soto

---

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

See you later with another edition — Saurabh