Six views of one system, from what talks to what down to what is stored in which
column. Each one runs scenarios: pick one, press Run it, and watch a real request cross the
diagram with the reasoning as it goes. Every number here is the number the server enforces.
This is published because the design is more useful in the open than in a private
repository, and because the parts we are least sure about are the parts worth arguing with.
If something here is wrong, or right for the wrong reason, we would like to hear it.
1. What talks to what
Two containers, one database, a scheduler. Everything else is somebody else's service. Pick a scenario and watch a real request cross it.
—
Press Run it, or click any box to read what it is and why it is there.
Click a box in the diagram above.
2. One enum drives both apps
Every screen in both apps is a function of this. Transitions are enforced on the server: an illegal move is a 409 with a sentence explaining it, not a silent failure.
—
Press Run it, or click any box to read what it is and why it is there.
Click a box in the diagram above.
3. How a job finds a photographer
The hardest thing in the product, and the one with no queue in it. Deterministic ranking, small waves, and a race that resolves in one UPDATE.
—
Press Run it, or click any box to read what it is and why it is there.
Click a box in the diagram above.
4. How a photograph gets from one phone to another
Three calls, and the middle one never touches the API. The interesting part is what happens to a file that silently fails.
—
Press Run it, or click any box to read what it is and why it is there.
Click a box in the diagram above.
5. What is actually stored
Ten tables. Every fact that must survive a restart is a row, and nothing important lives only in memory. Click a table to see why it exists.
—
Press Run it, or click any box to read what it is and why it is there.
Click a box in the diagram above.
6. Where it runs, and what it costs
Two Cloud Run services, a managed Postgres, three buckets and a scheduler. No load balancer, no VPC, nothing to patch. About ₹1,200 to ₹2,500 a month at pilot traffic.
—
Press Run it, or click any box to read what it is and why it is there.
Click a box in the diagram above.
What would make us change it
The architecture is deliberately small: two containers, one database, no queue, no cache tier,
no Kubernetes. That is a choice for pilot scale, not a belief about scale in general. Each piece
we might add has a number written down that has to be crossed first, so the decision is made by
measurement rather than by whoever read an article that week.
What we would add
What has to be true first
A load balancer with Cloud Armor
First abusive traffic, or the first day over 50,000 requests
Cloud SQL in Mumbai instead of Neon
Database cost passes what a small instance costs, or you need a VPC
Pub/Sub instead of the scheduler tick
The tick regularly takes longer than a minute
Memorystore for live positions
More than about 500 location writes a second
A read replica
Ops dashboards start slowing bookings down
Splitting a service out
One part of the code needs a different release cadence, and two teams are waiting on each other
GKE Autopilot
Not before several teams. Cloud Run stops being enough long after the pilot
Tell us where this is wrong
Particularly: the single API instance, dispatch without a queue, polling instead of sockets,
and putting the buckets in a different region from the services. Those are the four we argued
about most, and the four most likely to be wrong. If you are designing something similar, the
trade-offs are all written down above rather than hidden in the code.