Every developer building a side project or a home automation pipeline eventually hits the same roadblock. You have a script running in the cloud (maybe a web scraper, a webhook handler, or an AI agent), and you need it to trigger a physical action on a local device—like an old Android phone running Termux, or a Raspberry Pi behind a strict home firewall.
The standard industry advice is immediate: "Just spin up Celery and back it with RabbitMQ or Redis." But for independent developers, indie hackers, and hobbyists, that answer feels terrible. Deploying and maintaining a heavy, memory-hungry message broker infrastructure for low-to-medium workloads is massive operational overkill. It’s expensive,
introduces vendor lock-in if you go the managed cloud route, and forces you to manage background daemons that eat up system resources.
The alternative? Opening inbound network ports or setting up reverse SSH tunnels, which is a security nightmare.
That is why I built Intent Bus—a zero-infrastructure job coordination system powered entirely by a minimal Flask core and a local SQLite database. Instead of maintaining persistent stateful connections or heavy external brokers, your cloud script simply writes tasks to an HTTP endpoint, and your cross-device edge workers safely poll for jobs using basic outbound HTTP requests. It gives you atomic locking, priority scheduling, exponential backoffs, and dead-letter queues out of the box with zero operational friction.
But when you tell developers you built a concurrent message queue on top of SQLite, the skepticism is instant. "SQLite has a single-writer bottleneck." "It will thrash the disk." "It can't scale under real worker contention."
We just launched live on Product Hunt, and my co-maintainer Zan and I decided to stop talking about theory. We decided to break it. Here is how we stress-tested Intent Bus across the cloud, the limits we hit, and the completely unexpected way an old smartphone stole the show.
The Testing Strategy: Finding the Ceiling
To find exactly where our architectural trade-offs would give out, we established a rigorous profiling matrix across three distinct deployment environments:
- PythonAnywhere (Free Tier): A standard python hosting environment.
- Render (Free Tier Docker Container): A typical lightweight cloud container setup.
- Android 12 Device (Termux via local ARM CPU & Flash Storage): True edge hosting.
We subjected the broker to progressively brutal worker/job ratios to watch the latency curve and catch database locks or lease drops in real-time.
| Profile | Concurrency Workload |
|---|---|
| Low | 5 active workers polling and fulfilling 50 total jobs. |
| Medium | 15 active workers polling and fulfilling 500 total jobs. |
| Heavy | 40 active workers polling and fulfilling 2,000 total jobs. |
| Extreme | 100+ active workers polling and fulfilling 5,000 continuous jobs. |
Phase 1: The Cloud Baseline (PythonAnywhere vs. Render)
We kicked off our benchmarks on a PythonAnywhere Free Tier instance. The results were an immediate failure under any real load. Because the free tier utilizes single-threaded request handling, concurrent workers polling the queue quickly created an unrecoverable request backlog. At medium load, it hit 100% network errors. Single-threaded processes are completely non-viable for worker polling loops.
Next, we shifted to a multi-threaded Docker deployment on Render's free tier. This is where the SQLite architecture started to shine.
- On Medium load, Render sailed through with a 99.5% success rate, averaging 11.30 jobs/sec with a tight P99 worker latency of just 0.517 seconds.
- When we pushed it to Heavy load (40 workers, 2,000 jobs), the system held steady at a 99.34% success rate and maintained a 14.18 jobs/sec throughput.
Because we engineered Intent Bus around a strictly optimized SQLite Write-Ahead Logging (WAL) configuration, the database handled concurrent reads comfortably. Under heavy writer contention, our locking mechanism gracefully degraded—tail latencies extended out to a P99 of 2.891 seconds, but the queue never crashed, never locked up, and leaked exactly zero jobs.
Phase 2: The Android Experiment (Pushing to the Extreme)
With a stable cloud baseline of ~14 jobs/sec, we decided to run an unconventional experiment: What happens if we host the central message broker right on the edge? We spun up the Intent Bus server inside Termux on a standard Android 12 phone, using its internal ARM processor and mobile flash storage as the entire infrastructure backbone.
The results completely blew past our expectations.
When we unleashed the Heavy load test (40 workers, 2,000 jobs) against the smartphone server, the mobile hardware didn't just keep up—it completely crushed the cloud container, clocking an astonishing 28.04 jobs per second with a P99 latency of 2.556 seconds. Because the physical phone flash storage didn't have to contend with the shared cloud hypervisor overhead found on free-tier containers, SQLite local disk I/O operations executed at blistering speeds.
Pushing to the Absolute Brink: 5,000 Continuous Jobs
Emboldened by the phone's performance, we threw our absolute worst-case scenario at it: The Extreme Profile. We unleashed over 100 concurrent worker loops, firing a non-stop barrage of 5,000 jobs over a sustained 4.5-minute beating (267 seconds).
This is what real system engineering looks like when it hits a hardware wall:
- Graceful Degradation: As the mobile flash storage and ARM chip finally throttled under the sustained heat and massive file-write contention, our average throughput dropped from its peak down to a sustained 18.52 jobs/sec. Tail latencies spiked heavily, pushing the P99 worker response out to 9.002 seconds.
- Absolute Structural Integrity: Despite the hardware bottleneck, look at the error counters. Zero network drops. Zero lease losses. Zero publish rejects. Even when the device was gasping for air, the protocol's locking logic and database state transitions remained flawless.
- The Final Score: The system completed the marathon with a 98.89% success rate over 5,000 continuous tasks, proving it is virtually indestructible under load.
Architecture Takeaways: Why This Matters for Indie Devs
We didn't build Intent Bus to replace Kafka, RabbitMQ, or high-throughput enterprise systems. If you are building a multi-region corporate platform processing tens of thousands of requests per second, you need a traditional distributed broker architecture.
But if you are an indie hacker, a DevOps engineer tying personal scripts together, or an automation enthusiast coordinating a heterogeneous fleet of edge machines, these benchmarks change things.
They prove that a lightweight, properly optimized SQLite WAL backend is fundamentally robust enough to handle thousands of concurrent jobs with zero data corruption. It means you can completely bypass the cost and complexity of cloud server infrastructure. You can literally pull an old phone out of a drawer, install Termux, and host an incredibly reliable, self-contained, bulletproof automation queue entirely for free.
We are Live on Product Hunt!
Intent Bus is 100% open-source and written in Python. While we provide a dedicated Python SDK to handle signature generation and worker loops automatically, the underlying protocol is lightweight enough to interact with using nothing but pure bash and curl.
Our code is fully verified, our CI/CD pipelines are green, and our Product Hunt launch is officially live right now! If you want to check out the codebase, audit our security protocol updates, or leave us your honest feedback, check out the links below:
👉 Leave a Review on Product Hunt: https://www.producthunt.com/products/intent-bus/reviews/new
👉 GitHub Main Server: https://github.com/dsecurity49/Intent-Bus
👉 GitHub SDK Repo: https://github.com/dsecurity49/Intent-Bus-sdk
I’ll be hanging out in the Product Hunt comments section all day to answer your questions—I'd love to hear your thoughts on our SQLite implementation, our capability routing, or our edge-computing performance results!
Top comments (0)