It all started during one of my routine code reviews at work. I was reviewing a piece of functionality that had recently been implemented. The task was straightforward: a user dashboard needed to pull data from several services—user information, order history, and notifications. Our system was already built on a microservices architecture, and we had an API Gateway in place. Yet, there it was: the API Server orchestrating the entire process.

I couldn’t help but wonder: Why are we writing this business logic in the API Server? Shouldn’t the microservices handle this directly? And if the API Gateway is already routing the requests, why do we even need an API Server?

That lingering thought stayed with me throughout the day. Later, during a team discussion, I brought it up. I asked,

“If our microservices are already self-contained and handle business logic, why are we duplicating or centralizing some of it in the API Server? Doesn’t that contradict the very idea of microservices? And in this setup, what exactly is the role of the API Gateway?”

Key Concepts:

Microservices:

Each microservice is responsible for a specific business capability (e.g., user service, order service, payment service).
Microservices are independent and encapsulate their own business logic and database.

API Gateway:

A centralized entry point for client requests.
Handles routing, authentication, rate limiting, load balancing, and sometimes response aggregation.
It does not implement business logic but ensures smooth interaction between clients and microservices.

API Server:

A layer that might exist between the API Gateway and microservices.
Typically used in systems transitioning to microservices or where business logic is too complex to be directly handled by microservices.

Why Use an API Server Alongside Microservices?

1). Centralized Logic for Complex Use Cases

Sometimes, you need a layer to combine data or functionality from multiple microservices.
Instead of embedding complex orchestration logic in the client or microservices, the API Server acts as a mediator.
Example:
You have a User Service and an Order Service. To show a user’s dashboard, you need to combine data from both. The API Server orchestrates these calls and merges the responses.

2). Legacy Support or Gradual Migration
In systems transitioning from monolithic to microservices architecture, the API Server may still house some business logic until the migration is complete.
Example:
A monolithic application is being broken into microservices, but the API Server still handles user authentication logic until a dedicated service is created.

3). Abstraction for Clients
The API Server can expose a unified API to clients, abstracting the complexity of multiple microservices.
Example:
Instead of the client calling /users, /orders, and /notifications separately, it calls /dashboard, and the API Server coordinates with the microservices.

What Does the API Gateway Do Then?

The API Gateway focuses on cross-cutting concerns and provides system-wide functionality. Its role complements, rather than overlaps with, the API Server.

API Gateway Responsibilities:

1).Routing:
Directs requests to the correct microservice or API Server.

2).Authentication and Authorization:
Validates tokens or API keys before forwarding requests.

3).Rate Limiting and Throttling:
Ensures no client overloads the system.

4).Caching:
Reduces load on microservices by caching responses.

5).Load Balancing:
Distributes traffic among multiple instances of a service.

6).Request Transformation:
Converts incoming requests or modifies responses (e.g., converting
XML to JSON).

When You Don’t Need an API Server

If your microservices are fully self-contained and lightweight, the API Gateway can directly route client requests to them, eliminating the need for an API Server.

Example:

Client -> API Gateway -> Microservices (User Service, Order Service, etc.).

This approach works well for:

• Systems with simple orchestration needs.
• Microservices designed with minimal dependencies and clear APIs.

When You Need Both API Server and API Gateway

1). Complex Orchestration:

If multiple microservices must work together to fulfill a request.
Example: Generating a report that requires data from User, Order, and Analytics Services.

2). Centralized Business Logic:

If business logic spans across multiple microservices.
Example: Calculating discounts based on user history, current promotions, and payment method.

3). Client Simplification:

Clients interact with a single API endpoint exposed by the API Server, while the server coordinates with microservices.

CONCLUSION

If your microservices can directly handle requests, you might not need an API Server. However, if there is complex business logic that spans multiple services, an API Server becomes useful. The API Gateway is always essential for routing, security, and system-wide tasks.