SARWAM
As a founding engineer, I built backend services for buyer, logistics, and internal operations workflows, plus the data model, delivery matching, notifications, and releases.
- Focus
- Backend systems · delivery matching
- Built with
- TypeScript · Go · PostgreSQL · AWS
- When
- February 2026 to August 2026 · Remote
- Role
- Founding Engineer
What I built
SARWAM needed backend workflows that connected shopping, payment, delivery, and internal operations. I built services for those flows while the product was taking shape, and worked on the database and deployment path they depended on.
- Buyer and operations services for catalog search, carts, orders, Cashfree payments, KYC, settlements, and analytics.
- A Supabase PostgreSQL model spanning more than 25 tables, with row-level security, functions, and triggers for ratings, delivery OTPs, and payout reconciliation.
- A TypeScript / Hono logistics API, an internal Go matching engine, and a shared Firebase Cloud Messaging service.
- Separate Docker releases for the API and matching engine on AWS EC2, delivered through GitHub Actions and GHCR.
How it works
A client calls the public API
The TypeScript / Hono service handles authentication and application workflows. It reads and writes persistent data through Supabase and forwards matching requests to the internal Go engine.
The Go engine finds delivery candidates
The engine keeps available delivery bundles, driver locations, and active-delivery state in memory. Matching reads that state without querying the database on each request. Timeouts, expiry, and reconciliation manage stale state.
Acceptance updates durable state
Driver acceptance uses an atomic database operation so competing requests cannot both take the same delivery. The API then updates the engine cache to remove the accepted bundle and mark the driver active.
Shared services and releases support the workflow
A stateless FCM service handles shared notification requests from the buyer, seller, and logistics backends. Separately, the API and engine ship as Docker images, with health checks and rollback in the release process.
Engineering decisions
Separate public API and matching state
TypeScript / Hono owns the public application boundary. Go owns in-memory matching. This keeps repeated matching reads away from the database while leaving persistent business data in PostgreSQL.
Keep acceptance atomic
Matching suggestions come from memory, but accepting a delivery changes durable business state. The database operation protects acceptance against competing drivers; cache updates then reflect that result.
Treat cache recovery as part of matching
In-memory state can miss an update or outlive a delivery. Timeouts, expiry, and reconciliation make recovery part of the design, rather than assuming memory always matches the database.
Make releases identifiable and reversible
I deployed separate API and engine images through GitHub Actions and GHCR to EC2. Commit SHA releases identify the code being deployed. Health checks and automatic rollback provide a recovery path for a failed release.
Scope of my role
I worked as a founding engineer on SARWAM. The responsibilities described here cover my backend services, data model, matching engine, shared notifications, and release work within the product team.
The key design lesson was separating fast matching from durable acceptance. In-memory state supports repeated matching requests, while atomic database operations protect order state when drivers compete for a delivery.
What this work demonstrates
This work connects API design, relational data modeling, concurrent matching, and release operations. I worked across those boundaries while SARWAM was taking shape, with responsibility for the backend components described here.
The company repositories are private. This page explains my contribution without publishing their code or internal configuration.
Explore my public projects