
Explore how to build an application capable of handling one million requests per minute through architecture guidance, step-by-step problem solving, and KPI-driven memory leak avoidance.
Explore building a Golang system to handle one million requests per minute, addressing memory leaks, telemetry, and scalable queues with channels, workers, and an elastic load balancer.
Explore how to build a Golang handle function to process one million requests per minute by orchestrating a dispatcher, workers, and a job queue with channels.
analyze memory leak issues in high-traffic api paths, tracing across mobile clients, gateways, and services, and implement strategies to reduce memory usage, improve response times, and prevent outages.
Configure a reusable http client with a default transport and a two-second timeout, reuse connections per host, and manage client IDs to reduce call latency.
Close the response body to prevent memory leaks and exhausted connections. Read or discard the response data properly to avoid production disasters.
Focus on a simple time channel approach to manage concurrency in Golang, coordinating data from Facebook and Twitter, handling API errors, and avoiding timeouts to keep response times fast.
Discover how to use Go context and timeouts to manage requests, keep background tasks safe, and improve reliability in high-concurrency servers.
The Problem
While working on a piece of our anonymous telemetry and analytics system, our goal was to be able to handle a large amount of POST requests from millions of endpoints. The web handler would receive a JSON document that may contain a collection of many payloads that needed to be written to Amazon S3, in order for our map-reduce systems to later operate on this data.
Traditionally we would look into creating a worker-tier architecture, utilizing things such as:
Sidekiq
Resque
DelayedJob
Elasticbeanstalk Worker Tier
RabbitMQ
and so on…
And setup 2 different clusters, one for the web front-end and another for the workers, so we can scale up the amount of background work we can handle.
But since the beginning, our team knew that we should do this in Go because during the discussion phases we saw this could be potentially a very large traffic system. I have been using Go for about 2 years or so, and we had developed a few systems here at work but none that would get this amount of load.
Conclusion
Simplicity always wins in my book. We could have designed a complex system with many queues, background workers, complex deployments, but instead we decided to leverage the power of Elasticbeanstalk auto-scaling and the efficiency and simple approach to concurrency that Golang provides us out of the box.
It’s not everyday that you have a cluster of only 4 machines, that are probably much less powerful than my current MacBook Pro, handling POST requests writing to an Amazon S3 bucket 1 million times every minute.