Scaling an API to ~8,000 successful RPS.
Designed service boundaries and RabbitMQ contracts for a busy HR backend; the team separated bot and background workloads.
The challenge
A burst of user activity exposed a weak point in a central backend API. HTTP requests, bot interactions and background work competed for resources, and users sometimes saw 503 responses or timeouts.
My role
I defined service boundaries and RabbitMQ contracts and reviewed the implementation with two developers. They wrote the extracted-service code; I owned the architecture decisions and validated the outcome in production monitoring.
Engineering approach
We moved the Telegram bot and background jobs into separate services, introduced RabbitMQ interactions and an Outbox flow for notifications. In parallel, the team increased Granian Python workers from one to four and raised CPU/RAM limits without adding Kubernetes pods.
The outcome
Peak successful HTTP throughput on the main API grew from about 1,500 to about 8,000 requests per second. At the later observed peak, the Grafana 5xx metric stood at zero.
We also compared old and new architectures with fixed Granian workers and CPU/RAM limits; no numeric result from that controlled comparison is available. The ~5.3× figure compares successful HTTP 2xx/3xx RPS from one Nginx/Grafana panel and five-minute window after combined architecture and runtime changes.