Savana: The Checkout Bot That Turns Flash Sales Into a Timing Engine
A reverse-engineered automation stack that splits the race into scheduler, workers, proxies, and a human payment handoff.
- Savana is built around timing first, because the sale is won or lost before most checkout flows even begin.
- Its real trick is architectural: it strips away browser work where possible, then uses API calls, session reuse, and proxy routing to keep the path short.
- The dashboard is a cockpit, not the engine, because one operator still has to steer many moving parts at once.
- The project turns checkout into a staged pipeline, with human payment completion preserved as the final controlled step.
The race starts before the sale
Savana is not interesting because it automates a checkout form. It is interesting because it treats a flash sale like a latency budget. The critical moment is not the click. It is the warm-up, the queue drain, the jitter, and the handoff that happen before the click lands.
The scheduler in src/core/flashScheduler.js uses a coarse-to-fine timing strategy. It arms early, then tightens into a fast spin loop close to T-0 so Node’s event loop drift has less room to matter.
// Simplified from the flash scheduler pattern
setTimeout(() => {
warmup();
const tick = setInterval(() => {
if (saleWindowOpen()) {
triggerQueueDrain();
clearInterval(tick);
}
}, 5);
}, 500);Reverse-engineering the path to checkout
The repository’s Burp XML traces and payload extraction scripts are the giveaway. Savana is not only driving a browser. It is reconstructing network behavior so it can use the shortest path available when speed matters.
That changes the whole shape of the tool. Instead of paying browser overhead for every step, the bot can replay API-like calls, persist sessions, and reserve the browser for edge cases. The project’s request layer is closer to a protocol adapter than a macro recorder.
The queue does not stop for one bad account
Savana’s executor treats accounts like workers draining a shared queue. If one account gets rate-limited, the rest keep moving. That sliding-window model is what keeps throughput alive when the platform starts pushing back.
The system also adds jitter to avoid lockstep bursts. That matters because a synchronized burst is easy to spot, and easy to throttle. The code is doing operations work as much as it is doing automation.
| Dimension | Browser-only bot | Savana hybrid stack |
|---|---|---|
| Speed | Pays browser overhead for most steps | Uses API-style requests where possible |
| Detection surface | Broad browser fingerprint surface | Smaller request path, browser only when needed |
| Operational complexity | Simple to describe, harder to tune | More moving parts, but each part has a narrower job |
| Reliability under load | Can bog down when sessions or UI drift | Keeps draining through queue-based workers |
| Human intervention | Often needed throughout | Mostly reserved for the final payment handoff |
| Dependency on browser state | High | Selective and limited |
That comparison is the point. Savana does not try to win by making the browser faster. It wins by making the browser less important.
The dashboard is not the bot. It is the cockpit
The React and Next.js dashboard is a control surface over the system, not the system itself. WebSockets push live state back to the operator so campaigns, workers, and failures can be monitored without polling the app to death.
That separation matters. Once the automation stack becomes distributed across workers, sessions, proxies, and fallbacks, the human needs a cockpit. The dashboard exists so one person can steer the race without losing visibility.
The result is a useful pattern for any hard automation problem: push execution down into narrow services, then let the UI focus on decision-making, not mechanics.
Why Savana is faster than a browser-only bot
Savana’s hybrid stack is the real thesis. It uses reverse-engineered API calls for speed, Puppeteer Stealth where browser behavior is still needed, a Python curl wrapper for edge cases, session persistence to avoid re-authentication, and a manual Juspay handoff for the final payment step.
Scheduler -> Queue -> Workers -> Session / Proxy Layer -> Request Engine -> Payment handoff
↘ API-first path
↘ Browser-assisted fallbackEach layer removes a different kind of waste. The request engine avoids browser friction. Session reuse avoids login friction. Proxy selection reduces transport risk. The manual payment handoff preserves the one step that is most brittle to fully automate.
| Layer | What it saves | Why it matters |
|---|---|---|
| API-first requests | Browser overhead | Lower latency at the hottest part of the flow |
| Session persistence | Repeated auth | Fewer OTP and re-login interruptions |
| Proxy warm-up | Cold connection delay | Less drift at T-0 |
| Manual payment handoff | Fragile automation at the end | Keeps the final step controllable |
What this project says about flash-sale automation
Savana reads like a case study in specialization. It is not a general bot framework. It is a purpose-built race car, tuned for one narrow track where transport, timing, concurrency, and handoff all matter more than elegance.
That is why it feels modern. The interesting software is not always the one that automates everything. Sometimes it is the one that knows exactly which parts should stay human, which parts should be queued, and which parts should never touch a browser at all.