Skip to main content
A
// CASE FILE 01 / 19
← All case files

Aero

ClientLIVE IN PRODUCTION · 4 APPS · AWSFastAPIFlutterPostgreSQLRedisAWS VISIT LIVE SITE ↗
01> HOW IT SHIPPED
// THE CHALLENGE01

A city-scale ride-hailing platform was carrying rides, drivers and payouts on a backend that could stall as a single unit: one blocked event loop took health checks, dispatch and booking down together, and the analytics everyone needed ran against the same live tables the riders did.

// THE APPROACH02

Rebuilt the core as a two-worker FastAPI service with a circuit breaker on every hot Redis path, cluster-safe queueing with a fallback queue behind it, and reporting moved off live tables onto materialised views refreshed on a schedule — revenue by day, performance by provider, demand by hour of the city.

// THE OUTCOME03

Customer app, provider app, vendor console and web run against one hardened core in production on AWS. A stalled dependency now degrades one path instead of the platform, and a question about last month's demand is answered in seconds rather than avoided.

case --info aero-platform
> client · Aero
> sector · Mobility
> stack · FastAPI · Flutter · PostgreSQL · Redis · AWS
> result · LIVE IN PRODUCTION · 4 APPS · AWS
> case/aero-platformSHIPPED ▮

Want a system like this?

Tell us what you're building. We'll respond with a scoped plan, not a sales pitch.