scaling-load-assumptions

Load test by simulating production-scale traffic with tools like k6, Gatling, JMeter, or Locust in a production-like environment. Run smoke, load, stress, soak, and spike tests, tracking P95/P99 latency, throughput, error rate, and resource saturation.

An N+1 query pattern issues one database query per item in a list, so 1000 users trigger 1001 queries. Fix it with eager loading to fetch related data in a single query, plus caching for frequently accessed records.

k6 offers modern JavaScript scripting and suits cloud-native systems, Gatling uses a Scala DSL with efficient async architecture, and JMeter is mature and full-featured but more cumbersome. For modern web systems, k6 or Gatling are common starting choices.

Load failures often appear as sharp cliffs rather than gradual degradation: linear scans time out, caches hit memory limits, or third-party APIs throttle requests. Stress test to find the breaking point and provision capacity at 50-75% of it.

Queue requests locally and process them at the rate the API allows, showing users an in-progress state for delayed operations. Also negotiate higher limits with the provider and add a backup provider for failover.

Add caching and sharding when measurements show bottlenecks, not prematurely, but design the architecture so these can be added later. Start simple, load test at production-target scale, and monitor utilization to detect approaching limits.