Bangalore, India

Shailendra Singh

Senior Backend Engineer · Go

I build distributed backend systems that stay correct under load, retries and partial failure: ledgers, event pipelines, deadline-bound services, and the infrastructure they run on.

/01  Selected work

Each one is written up as a small design doc: the problem, the constraint that shaped it, the design, what it cost, and the numbers.

01  Low latencyCode ↗

Real-time order matching with disk off the hot path

A Go matching engine on an in-memory order book. Matching never waits on a write; persistence happens asynchronously downstream, and the book is rebuilt by replay after a crash.

45K+/s
orders matched, benchmarked
500+/s
orders settled on-chain in production
<1 ms
match latency
  • Go
  • PostgreSQL
  • MongoDB
  • RabbitMQ
  • TypeScript
02  Scalability, measuredCode ↗

Finding where a read-heavy service actually breaks

A URL shortener in Go, load-tested with k6 against real Postgres and Redis until it broke. Every number is measured on one laptop, and the most useful findings are the bugs that only appeared under load.

37,893/s
redirects, p95 2.32 ms, 0 errors
12,141/s
writes, p95 6.41 ms, 0 errors
99.86%
of reads served from Redis
  • Go
  • PostgreSQL
  • Redis
  • nginx
  • k6
  • Docker
03  Ledgers & correctnessprivate code

A credit ledger where a race cannot double-apply money

The backend of a revolving line of credit, modelled as a state machine over an append-only ledger. Invariants live in the database, not the application, and events arrive from two independent sources so none are lost or applied twice.

0
floats anywhere in the money path
2
independent event sources, reconciled
1
place each rule lives: the database
  • TypeScript
  • PostgreSQL
  • Docker
  • GitHub Actions
  • AWS
04  Concurrency & latencyprivate code

A deadline-bounded auction under a 12-second window

The core auction path of a latency-sensitive Go service. It fans out requests to many upstreams at once and must return the best answer it has when the deadline hits, because a late answer is worth nothing.

12 s
hard window, missing it wastes the round
94% → 99.5%
hit rate after moving the cutoff
~5%
late bids traded away for it
  • Go
  • goroutines
  • context
  • gRPC
  • AWS Lambda
  • SQL
05  Platform & infrastructureprivate code

Provisioning a full production stack from one command

A Go SDK and CLI that provisions cloud infrastructure, deploys a multi-service stack to Kubernetes, verifies it, and tears it down cleanly. Built so a failure halfway through never strands the operator.

days → 1 cmd
manual setup replaced by the CLI
4
engineers led across SDK, backend, platform
resumable
a failed deployment restarts from one command
  • Go
  • Kubernetes
  • Helm
  • Terraform
  • TypeScript
  • PostgreSQL
06  Networking & cryptographyCode ↗

Forward-secret messaging over relays that cannot read it

A peer-to-peer messaging node in Go. Messages route over gossip, get stored for peers that were offline, and are end-to-end encrypted with a Double Ratchet, so stealing one key opens exactly one message.

31
tests, no network needed
1
message opened per stolen key
4
real bugs found and written up
  • Go
  • libp2p
  • gossipsub
  • X25519
  • HKDF
  • Double Ratchet

/02  About

Six years building backends where correctness is the product: two systems of record that must agree, retries that must be harmless, and deadlines that do not move.

Most of that work has been in Go, with TypeScript, Python and Rust where the job needed them. I have built the ledger behind a revolving credit product, a real-time auction that answers inside a 12-second window, and an SDK that provisions full production stacks on Kubernetes.

The problems I like are distributed-systems problems: idempotency, ordering, reconciliation, partial failure, and knowing exactly what happens when an upstream is slow or wrong. I like owning a system end to end, from the API and schema to the deploy and the dashboard that tells us when it breaks.

Currently a Senior Backend Engineer at Qiro Finance in Bangalore, building the backend of a fintech credit product.

/03  Experience

04/2026 to presentQiro FinanceSenior Backend Engineer · Bengaluru

Fintech, private credit. I own the backend of the revolving credit product.

  • Designed the accounting system behind a revolving line of credit: borrowing, repayment, missed payment and recovery as an explicit state machine over an append-only ledger.
  • Made the money math provably correct: arbitrary-precision integers instead of floats, deterministic replay from the event log, and invariants enforced as database constraints so two workers racing on one event cannot both commit.
  • Built event ingestion from two independent sources, push webhooks plus a polling scanner, with idempotent writes and automatic gap detection and backfill, so no event is lost or applied twice.
  • Cut latency on customer-facing balance APIs by caching an expensive multi-source aggregation, with per-field TTLs set by how fast each value can legitimately change.
  • Built CI/CD in GitHub Actions: integration tests against an ephemeral Postgres container on every PR, automatic deploys to AWS on merge, and concurrency gating so stale runs cancel instead of racing.
  • TypeScript
  • Go
  • PostgreSQL
  • Docker
  • GitHub Actions
  • AWS
07/2024 to 03/2026Tokamak NetworkSenior Backend Engineer · Remote

Infrastructure platform. Led a team of four across SDK, backend and platform.

  • Built a Go SDK and CLI that provisions cloud infrastructure, deploys a full service stack to Kubernetes with Helm, wires networking, monitoring and explorers, and tears it down cleanly. Replaced days of manual setup.
  • Made the multi-step deployment flow resumable from a standalone command, with verification checks and incremental backoff, so a failure halfway through no longer strands an operator.
  • Built the TypeScript backend behind the platform: auth, the Postgres schema and access layer, and retries with idempotent handlers so a flaky upstream cannot corrupt deployment state.
  • Owned observability in Prometheus and Grafana, and used those dashboards to diagnose live incidents rather than only to display metrics.
  • Go
  • TypeScript
  • Kubernetes
  • Helm
  • Terraform
  • PostgreSQL
  • Prometheus
12/2020 to 07/2024SyvoraSoftware Engineer · Remote

Backend consultancy. Long engagements on a derivatives exchange and on a real-time auction system for Blockswap Labs.

  • Built the core of a deadline-bounded auction in Go: concurrent fan-out to many upstreams under a hard 12-second window, returning the best answer received when the deadline fires. Tuned the cutoff from real latency data, raising the hit rate from 94% to 99.5%.
  • Designed that system as independent modules over gRPC so new providers plug in without touching core logic, and debugged real goroutine races in the fan-out path.
  • Built a real-time order matching engine in Go on an in-memory order book, keeping disk off the hot path with async persistence and crash recovery by replay.
  • Built event pipelines on RabbitMQ into PostgreSQL and MongoDB, high-concurrency workers for order management and settlement, and peer-to-peer state sync with leader election.
  • Built serverless analytics on AWS Lambda feeding a SQL database behind an internal reporting dashboard.
  • Go
  • TypeScript
  • gRPC
  • RabbitMQ
  • PostgreSQL
  • MongoDB
  • AWS Lambda
2015 to 2019B.E. Computer EngineeringInstitute of Engineering and Technology, DAVV · Indore
View full resume ↗

/04  Open source

Code you can read and run.

/05  Notes

Short write-ups of things that were not obvious until they broke.

All notes ↗

Stack

Languages

  • Go
  • TypeScript
  • Python
  • Rust
  • SQL

Backend & data

  • PostgreSQL
  • Redis
  • MongoDB
  • RabbitMQ
  • gRPC
  • REST
  • WebSockets
  • NestJS
  • Django

Infrastructure

  • Docker
  • Kubernetes
  • Helm
  • Terraform
  • AWS
  • GCP
  • GitHub Actions

Reliability

  • Prometheus
  • Grafana
  • k6 load testing
  • idempotency
  • caching
  • distributed systems

/06  Contact

Building something where the money has to add up? I would like to hear about it.