How can you design APIs that handle large amounts of traffic?

Before going full REST, you need to consider gRPC. gRPC may be a more suitable choice if you want performance, benefiting from binary serialization with Protocol Buffers (protobufs) and HTTP/2 multiplexing. This makes it particularly good in scenarios involving large amounts of data or that require high throughput, such as microservices architectures and real-time apps. Also, one possible advantage of gRPC is the contract that clients must follow when communicating with the server. Moreover, interacting with gRPC clients has become more natural and easier compared to the past. Now, there are tools like Gloo or grpc-gateway that facilitate the generation of REST exposure, making it easier for clients to interact with gRPC.

Designing APIs that can handle large amounts of traffic requires careful consideration of several factors: Scalability: Ensure your infrastructure can scale horizontally to accommodate increased traffic. Use load balancers and distributed systems to balance the load effectively. Caching: Implement caching mechanisms to store and quickly retrieve frequently requested data. This reduces the load on your servers and improves response times. Rate Limiting: Implement rate-limiting strategies to control the number of requests a client can make within a specific timeframe. Asynchronous Processing: This allows your API to quickly respond to incoming requests while processing resource-intensive operations separately.

It depends on your use case. What is the size of each request? Do you have one offs with large amount or do you have many with small amount? What are you going to return in your API? REST will probably work for the most ones in the beginning. Easy to implement and enough examples out there. Try not to start with microservices out of the box. If you have more services than engineers, you definitely have a problem. Sometimes binary protocols can be helpful. In a few cases you need RPC style.

Every engineers solution is to cache if the API gets slow, but caching is hard stuff. This often means the APIs are not well designed or the underlying access to other services. For static content, caching is easy, but the moment where you have to revoke it, because it is changing, it will get tricky. How to ensure all servers are up-to-date? How to ensure the client got the fresh one. And often the first call is still slow, because you can’t pre-cache for all clients. Make use of client-side caching. Make use of CDNs. But the moment where you start implementing your own caching algorithms with local hard disk and so on, try to figure out why you have to cache and solve the issue.

Applying it isn’t that hard anymore, but make sure you monitor it. Check where you want to have it and where you should better not have it. Example: login endpoint always should have it. It should not be possible to run a high scale brute force attack against it. Product listing endpoint should probably not have it, because you want to make sure, your customers always gets it. I reviewed once a company where you had to click 5 times pretty fast and you got banned for 30min. It was an eCommerce company. So the worst what could happen. A customer can’t but, because they clicked faster than normal. Apply, monitor, adopt.