Real load reports from apps we run ourselves

One shop, three situations

We run an open-source shop (Medusa v2) on Railway and send it the traffic of real visits: browse, search, open a product, add to cart, pay. Then we look for the rate where it stops keeping its promises.

Each column is a capacity search. Green is the rate the shop held with every step inside its latency bound; the hatched stretch is where the limit lies; red is where it broke. The shops share the application and its limits, but their databases were not capped and warmed up differently, so the columns compare three observed setups, not the effect of data volume alone.

The visit we replay

Every scenario sends the same kind of visit, step by step, the way a shopper moves through the store. The bars are each step's share of all requests in the small-catalog run; the Black Friday visit shifts weight from browsing to carts and orders at a steady rate, without a traffic spike.

One taxi backend, three evenings

We run a ride-hailing geo backend on Railway: Tile38 holds live driver positions and open orders, OSRM routes over the Moscow road graph, Photon geocodes addresses, and one Caddy front door sits before them. 20,000 synthetic drivers move around Moscow and ping their positions; between the pings, riders look for a car, get a route and a price, and some of them order.

Each column is a capacity search. Green is the rate the backend held with every call inside its latency bound; the hatched stretch is where the limit lies; red is where it broke.

The journey we replay

Every tick of a journey is a driver sending its position. Some ticks also serve a rider: geocode the destination, find drivers within 2 km, route and price the trip, check surge in the rider's cell and, when the rider orders, ask for ETAs from the nearest drivers and store the order. The bars are each call's share of all requests in the first taxi scenario; rain and the stadium change the mix and where in the city it lands.