The backend is Go, stateless by design and horizontally scalable, with PostgreSQL as the source of truth for everything durable — including background work.
The centre of it is dispatch: when a booking is paid, a ride offer goes out in ranked waves, and the first valid acceptance closes it atomically. There is exactly one correct winner and money depends on it. If concurrency problems with real consequences interest you, this is the part to ask about.
What you would do
- Design and build ConnectRPC services in Go — new work is proto-first here, with no REST fallback
- Model data properly in PostgreSQL and write the SQL, using sqlc for type-safe access
- Work on the dispatch engine: ranked waves, eligibility, idempotent acceptance, give-back and retry
- Keep pure business logic separate from IO — functional core, imperative shell is a standing rule, not a preference
- Write property-based tests for the rules that carry money and time
What we are looking for
- Strong Go, including the concurrency primitives and when not to reach for them
- Real PostgreSQL depth: transactions, isolation levels, indexing, and why a query is slow
- You have built and operated HTTP services in production, and debugged them there
- Comfortable with Docker and a Kubernetes deployment path
- Professional English, written and spoken
Nice to have
- gRPC / Protobuf / ConnectRPC
- sqlc, golang-migrate
- Payments work, and the idempotency discipline that comes with it
How we hire
- 1. Your application. CV plus a short note. We read it; it is not filtered by a keyword matcher.
- 2. A conversation. Forty minutes about what you have built and what you want to build.
- 3. Real work. A problem from this codebase, discussed together. Not a whiteboard algorithm, and not an unpaid weekend project.
- 4. Offer. With the reasoning, in writing.