← Indexrsvapi

GET /work/rsvapi200 OK

02 / 08 · Backend service · 2026

RsvAPI

An event-ticketing backend where the last ticket can only be sold once.

A scalable ticketing backend built with Node.js and TypeScript. It covers the whole reservation lifecycle: events and tickets, reservations, and payment processing.

My role
Designed and built the service end to end.
Year
2026
Context
Personal project
Stack
  • Node.js
  • TypeScript
  • Express.js
  • PostgreSQL
  • TypeORM

01 / The problem

The problem

When many people go for the same limited tickets at once, naive code sells a seat twice. A ticketing backend has to stay correct under concurrent requests, not only on the happy path.

02 / My role

My role

Designed and built the service end to end.

03 / Decisions that mattered

Decisions that mattered

  1. 01

    Reservations run as transactions

    Creating a reservation and updating availability succeed or fail together, so the database never ends up half-updated.

  2. 02

    Explicit concurrency control

    Competing requests for the same ticket are handled deliberately, so a race condition can't push sales past what is available.

  3. 03

    Redis caching

    Frequently read data is cached in Redis to take pressure off PostgreSQL.

  4. 04

    Clean layers, checked edges

    Routes, business logic and data access stay separate. Input is validated with Zod, auth uses JWT, the API is documented in Swagger, and integration tests plus Docker keep it reproducible.

04 / The hard part

Making overbooking impossible rather than unlikely. The interesting work was in the concurrent paths, not the CRUD.

Stack

  • Node.js
  • TypeScript
  • Express.js
  • PostgreSQL
  • TypeORM
  • Redis
  • JWT
  • Zod
  • Swagger
  • Integration tests
  • Docker