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.
Top comments (17)
I think you need to consider the overall architecture. It sounds to me like the API server is unnecessary and might actually be a bottleneck that will affect scaling and performance.
Depending on the architecture, you may have an event-driven paradigm or some other need that necessitates communication between micro services. This does not have to be REST based. You might look at using queues, messaging platforms like Kafka or gRPC.
The bottom line here is that your technical needs should drive the design.
@phototrip_8f65aa1941692af Thank you for sharing your thoughts and for adding such valuable insights! The use case I described in the blog was meant to illustrate one approach and just differentiating their use and not suggesting, but you’re absolutely right.
Your suggestion to explore event-driven paradigms, queues, or messaging platforms like Kafka or gRPC for inter-service communication is spot on. These tools can indeed enhance scalability and performance, especially in systems with high concurrency or complex workflows.
Thanks again for contributing to the discussion! If you have any recommended resources or examples for designing such architectures, I’d love to hear about them. 😊
Wait you created and named API server for microservice just to merge data/response from multiple microservice right?
But what if you have to get Order or User data? I guess you hit their own url (redirect API gateway).
Then I think you API server is just a another microservice you just complicate it by putting API Service (since this is used for some combine data case only)
In observing that the API Server can be seen as another microservice. However, its purpose is slightly different:
It acts as a middleware layer to manage cross-service interactions.
This design can improve modularity and simplify clients by offloading orchestration and verification logic to a centralized service.
In systems without an API Server, clients or the API Gateway might need to handle these responsibilities, increasing complexity in those layers.
To get specific user data or order data ,
For straightforward, service-specific operations (like fetching order details or user information), the API Gateway can directly route requests to the respective microservices. The API Server comes into play only when there’s a need for:
Yes, the primary role of the API Server in this setup is to handle orchestration and aggregation for use cases where multiple microservices are involved. This approach abstracts the complexity for the client, providing a single, unified API endpoint. While this might seem like an added layer, it simplifies client-side interactions, especially for cases requiring combined or dependent data.
i) What if you have to update some data that makes changes to multiple services, so you use API Server in this case as well?
Or have to update data on some service what need to check/verify from other service, you use API server here as well?
Great question! In scenarios where updating data involves changes across multiple services:
The API Server helps keep microservices loosely coupled by centralizing coordination.
This is another key use case for the API Server:
Thank you, easy to read and understand. Looking for more.
You're welcome! @chetan_more_bb6c32cfcb360 I'm glad you found it helpful.
Instead of a single API server or gateway, use a domain and map the path using base path mapping.
Have each path map to it's own API gateway for maximum decopling and seperste the http layer from the service layer.
What are API Gateways usually made with? Are they web servers like nginx or are they runtime services like Nodejs or Java?
Makes me wonder if API Server and Gateway could be merged
@deadreyo Firstly, API Gateways can be built using different technologies depending on the requirements of the system.
It’s technically possible to merge an API Gateway and an API Server, especially if you have a small or simple system. However, in most cases, keeping them separate is beneficial due to their distinct roles.
In small-scale applications or monolithic architectures, merging the API Server and Gateway could reduce the number of components to manage.
Can web servers manage the authentication and token verification? I assumed no and that a runtime is required for these, due to needing to do complex computations or using a library (for JWT for example), or query the database to verify the token's body is valid.
It was thorough and detail, at least for me as a final year student trying to understand how things work in with complex business functionality and microservices.
Thanks!
Thank you for the kind words! @vedesh_padal