Let me tell you the tragicomic tale of how a side project almost killed our startup—and how async Python saved it, without anyone noticing. Which is exactly the point.
Act I: The Sync-pocalypse
It started innocently. We were building a simple analytics dashboard—you know, one of those “just pull from a couple APIs and display some charts” kind of things. So we whipped up a Python web app using everyone’s favorite default: Flask. It worked great. Locally. For a single user. At 3 a.m. with no data.
Then came our product launch for early adopters. People actually used it (who knew?). And suddenly, a single user refreshing the dashboard caused the entire app to seize up like a college student’s Wi-Fi during finals week.
Why? Because each click triggered:
- A 3-second call to a third-party API.
- A couple synchronous DB queries.
- A blocking file upload.
- And, for good measure, a Slack webhook because we were apparently that kind of startup.
Every request was a “nobody else gets through the door until I’m done” affair. We were concurrency-challenged, to put it politely.
Act II: The Non-Functional Dev Awakens
At this point, I did something brave. I opened the backlog titled “Performance/Tech Debt (Do Not Touch)”. I started rereading our project’s non-functional requirements like they were a breakup text. And it hit me: this wasn’t about features anymore — this was about quality attributes.
Responsiveness
People weren’t getting errors — they were getting nothing. A blank screen. That’s worse. Blocking API calls and DB queries meant the app couldn’t even start responding until all the work was done.
We needed async views, SSR with streaming if possible, and API calls that didn’t treat the event loop like a bus stop.
Scalability
Right now, we were basically serial-processing each user. Want to serve 5 users at once? Cool, just spin up 5 worker processes and pray. Async would let us share one event loop between many users, especially for I/O-heavy workloads like ours.
Availability
One third-party API being down meant the whole route failed. That’s not high availability, that’s shared suffering. Async would let us:
- Fire all the external calls at once,
- Timeout the laggards,
- And still render what we could.
Partial data >>> no data.
Maintainability
Half our problems came from hacking around blocking code. Threads. Locks. Signal handling. Async would let us write simple, readable, declarative logic — with await, not please-don’t-deadlock rituals.
Act III: From Blocking to Beautiful — Enter Quart, aiohttp, and databases
We didn’t rewrite everything. We just upgraded our brain.
First step: we ditched Flask for Quart — Flask’s cooler async sibling that actually speaks ASGI. It let us keep our beloved routing and templating style but run fully async views. No new religion required.
Then, we replaced:
| Old Stack | New Hotness |
|---|---|
requests | aiohttp |
psycopg2 | databases + asyncpg |
flask.render_template() | await render_template() (yes, it’s async too!) |
External APIs?
We used aiohttp.ClientSession to fire off multiple requests concurrently using asyncio.gather(). That took 9 seconds of wait time down to 2.
Database calls?
We swapped psycopg2 for the databases library with asyncpg under the hood. No ORM. Just plain SQL, async execution, and connection pooling that didn’t choke under pressure.
Rendering?
Quart’s async Jinja2 integration let us return rendered pages while other tasks were still running. We even experimented with streamed SSR, sending chunks of HTML as data came in. It was magic. Users actually saw something instead of waiting in the void.
Act IV: The Dashboard Reborn
Now, the dashboard loads in three phases:
- Initial page render (shell + partial data).
- Async API fetches complete and trigger dynamic inserts.
- Background DB updates queue silently, without blocking anything.
The result? Users feel speed, even when data sources are slow. We respond fast, even if not everything is ready.
Also:
- We built a fallback cache layer for failed APIs.
- A stalled DB connection doesn’t take down the entire app.
- We stopped overloading Postgres with connections.
Bonus win?
No more “why is the app frozen” Slack threads during lunch. That alone improved morale by 30%.
Act V: Async is the Best Kind of Boring
Here’s what we learned: performance isn’t always about raw speed — it’s about not wasting time. Async lets your app wait efficiently, and suddenly your code stops blocking, your server stops panicking, and your users stop rage-refreshing.
We didn’t change languages. We didn’t move to microservices.
We just stopped treating async like a futuristic luxury.
It’s not fancy. It’s just sensible.
Final Thoughts From The Non-Functional Dev
If your Python app:
- Waits on slow APIs,
- Talks to a database,
- Renders real HTML,
- Or pretends to be real-time,
Then you don’t need threads. You don’t need scale magic. Maybe you just need async.
Leave a Reply