Skip to main content

Scaling playground

Follow one shop from a single server to an enterprise setup. Raise the traffic, find what breaks and add the piece that fixes it.

Architecture

Clients

UsersBrowser and mobile

Application

ServerNode.js app and PostgreSQL on one VPS

From code to production

  1. Edit code
  2. SSH in
  3. git pull
  4. Restart

About 30 seconds of downtime per deploy, and no tests before production.

Healthy

40% of capacity

This setup handles the current traffic. Push the slider to find its limit.

Response time (p95)
180 ms
Capacity
500 req/min
Availability target
99%
Monthly cost
RM 40

Figures are rough estimates for comparing stages, not benchmarks.

01One server

What happened

Launch week. A small shop with a few hundred visitors a day, run from one VPS.

What changed

  • Node.js app and PostgreSQL on the same machine
  • Deploys by logging in and pulling the latest code

The trade-off

Cheapest and fastest way to start. But it is one machine: a bad deploy, a full disk or a busy database takes the whole shop down.

How I decide what to add

Grow when it hurts
Each piece arrives because of a measured problem, not a diagram someone liked. Running stage 8 for a stage 2 shop just burns money.
Stateless before scaled
Load balancing only works once app servers keep nothing on their own disk. That refactor usually matters more than the servers themselves.
Cache, offload, then replicate
Cheaper moves come first: cache repeated reads, push files to a CDN and slow work to a queue. Replicas and multiple zones come last.
Delivery grows too
How code reaches production matters as much as where it runs: from SSH and git pull, to CI and rolling deploys, to canaries with automatic rollback.