Open teaching lab

One flash-sale ticketing system,
seven backends, three mobile clients, one contract.

A concert goes on sale: far more buyers than tickets, all arriving at the same second. That one scenario forces everything worth teaching: stock contention, distributed locks, idempotency, a virtual queue, asynchronous payment, circuit breakers, and a load test whose entire job is to try to make you oversell. Solved on the backend seven times over, consumed by three offline-first mobile clients, and proven not to oversell.

7
backends, one contract
3
mobile clients, same contract
100/100
seats sold under load, 0 over-sold
14
recipes explaining the how

The premise, in three rules

  1. One contract. A single OpenAPI spec is the source of truth. Every backend implements it exactly; the frontend generates its client from it.
  2. The frontend is blind to the backend. It talks to one gateway. Switching the active backend is one line of config, and the frontend never changes. There is no if backend == … anywhere.
  3. Frameworks only do delivery. Business rules live in a framework-free service layer, so the framework becomes a swappable detail.
Three mobile clients

The same ticketing app in Kotlin Multiplatform, Flutter and React Native. One contract, offline-first, blind to the backend.

Seven backends

Go, FastAPI, NestJS, Express, Laravel, Symfony, Phalcon. Same behaviour, idiomatic in each.

Architecture

One contract as the source of truth, a gateway the clients are blind behind, and the same hexagonal shape inside every backend.

Recipes

Idempotency, distributed locks, no-overselling, async payment, JWT rotation, mTLS, caching, tracing. Each points at real code.

Decisions (ADRs)

Why the contract is one file, why the domain sits behind a service layer, why backends switch with one line.

The build

The construction story: one contract, a reference backend, six more, a frontend, three mobile clients, resilience, observability, scale.

Why I built this

This lab is a workout, not a product, and it isn't here to show off. Before moving to Sweden I worked as a mobile developer — native Android and iOS — and also fullstack (PHP, Node) and devops/SRE, so it exists to keep those muscles honest: to try languages I don't reach for daily (Go), sharpen my Python, and actually learn Flutter and React Native rather than nod along in meetings.

I picked a problem of medium complexity on purpose. A flash sale makes you get correctness right from the database up and then defend it through the API, the gateway, and every client, so one thread — don't oversell — runs the whole length of the stack: concurrency, security, and how a web app and three mobile clients consume the exact same contract. I've never held a grudge against a language, framework or platform. (Okay: ASP.)

I learned a great deal building it and I'm still learning. If any of it is useful to you, that's the point.

Jackson Mafra · LinkedIn