Five ways an API gateway can help flexible system design

When adopting a microservice architecture. A development team collectively makes the decision to take on significant pain. Testing becomes harder, consistency and transactionality becomes harder, and performance becomes harder. However, many teams consider sacrificing their happiness like this worth it for the three key advantages that you get with microservices. Independent deployability, Independent scalability and separation of concerns.

All three of these benefits can be enhanced and simplified by means of an API Gateway. But what is it?

API gateway

An API gateway is something that makes your application go from looking like this

To this

But what does this get you, other than a prettier looking picture?

Flexibility in Design

Designing microservices, deciding which part should go where, is hard. It involves an intense exercise of defining bounded contexts where each mini application is independent and scalable and have, a single or single group of responsibilities. But as requirements change and evolve, so does the landscape of the decisions you made. That’s hard, and like all hard things, we get them wrong. While I always think that it’s fine to get things wrong sometimes, you should have an architecture that agrees with that statement. An API Gateway, By acting as a central entry point for any client interaction, allows backend teams to reorganize their services without affecting clients.

In the previous example, imagine that the “Address Service” held both physical addresses and email addresses. But the advertising team wanted to now deliver two types of advertising, electronic and physical. On the back of this decision, the development team has decided that now is a good time to split the ‘Address Service’ into two In order to do that. Let’s explore what the team would need to do with and without an API gateway.

Without an API Gateway

If this solution looks precious, it’s because it is.

With no API gateway you’d need to do the following

1. Create new email service and pmail service
2. Inform all clients that the urls for the existing mail service endpoints are going to change
3. Ask all the clients to migrate to the new endpoints.
4. Wait for the clients to actually prioritize and perform those actions.
5. Implement changes.

In essence the issue here is that the team makes breaking changes. To avoid this we would need to maintain the old endpoints, leading to bad naming conventions, bad design and strange coupling. The only real way around this is to ask your clients to migrate to the ‘new’ endpoints. While that might seem fine, a battle-hardened developer or tech lead will tell you this might take several millennia.

In scenarios like this it’s common to hear people say things like “well, maybe for now we could just…. ”. This is a sure fire way to danger town.

With an API Gateway

With an API gateway you’d need to do the following

1. Create new email service and pmail service
2. Create a new optional field called ‘AddressKind’
3. Route new requests to either address according to the new ‘AddressKind’ field, if null send to both
4. Inform clients that they could use ‘AdressKind’ to route requests if they needed.

Since they can maintain the contract with clients, they don’t need to wait on anyone to get started. They can deprecate their old flows immediately.

In this example, we could see that the team with the API Gateway benefiting from several advantages.

1. Backend Service Independence

As previously alluded to, the API Gateway decouples clients from the individual backend services. Clients interact only with the API Gateway, unaware of the underlying microservices. This decoupling provides the flexibility to modify or replace backend services without impacting the clients. You can evolve and scale backend services independently, making it easier to introduce new services, decompose existing ones, or make changes to the internal architecture without affecting clients.

2. Request Transformation and Enrichment:

The API Gateway can perform transformations and enrichment of requests and responses. It can manipulate the data format, combine multiple requests into one, or split a single request into multiple backend service calls. This flexibility allows you to optimize the communication between clients and services by adapting the data payloads, aggregating data from multiple sources, or applying protocol translations as needed.

3. Service Composition

Aggregating data from multiple sources, with an API Gateway, leads quite quickly to conversations about aggregating multiple backend services into a single API endpoint.

This allows you to compose and combine functionalities from different services to fulfil specific client requests. How much of the composability (and complexity) you would like the API gateway to take on should be a topic of great debate within your team. How smart or dumb or thin or fat you decide to make your API gateway has huge design implications particularly around the areas of transactionality, consistency and service coupling. On the cleverer extremity, an API gateway will start to look more like a ‘workflow engine’ and on the more slender side a simple this ‘proxy’.

It might be wise in this area to consider the mutability of the data in various flows, as well as how synchronised various data sources might need to be as well.

4. Versioning and Backward Compatibility

The API Gateway can handle versioning and backward compatibility of APIs. It enables you to introduce new versions of services while still supporting older versions for existing clients. By managing API versions at the gateway level, you can maintain backward compatibility, gracefully handle deprecated endpoints, and gradually transition clients to newer versions without disrupting their functionality.

5. Request Routing and Load Balancing

The API Gateway acts as a central entry point for client requests and can dynamically route them to the appropriate backend services. This routing capability allows you to distribute traffic across multiple instances of a service, implement load balancing strategies, and scale services horizontally to handle increased demand. It provides flexibility in managing the routing and distribution of requests based on different criteria, such as geographic location, client type, or specific business rules. You could also leverage Request routing and load balancing in order to migrate clients from an old version of an API to a new one without requiring any changes from the client themselves.

Disadvantages

Coupling API Gateway and Backend Application Releases

One potential disadvantage of using an API Gateway is the coupling between the API Gateway and the backend application. When you need to introduce a new field or modify the response from the backend and expose it to the frontend, it requires coordinating the releases of both the API Gateway and the backend application.

This coupling can pose challenges in terms of deployment coordination, version compatibility, and potential release delays. Careful planning and communication are essential to ensure smooth integration between the API Gateway and the backend application.

Slight additional latency

Another potential disadvantage of using an API Gateway is the introduction of additional latency caused by the extra network hop. When a client makes a request to a backend service through the API Gateway, the request has to traverse an additional layer in the network architecture. This extra hop can result in a slight increase in response time, impacting overall system performance.

While the latency introduced by the API Gateway may be minimal, it can become more noticeable in scenarios where high-performance or real-time interactions are required. Applications that heavily rely on low-latency communications, such as financial trading systems or real-time gaming, may experience a noticeable impact on responsiveness.

It’s important to consider the trade-off between the benefits of using an API Gateway, such as centralized management and flexibility, and the potential latency introduced by the additional network hop. Proper performance testing and monitoring can help identify and mitigate any latency issues that may arise.

Any Latency added here of course, pale in comparison to the performance advantages you could get from implementing and API Gateway for Performance and implementing Patterns such as a Front loading cache API Gateway