Skip to content

Application quality · 7 min read

How do you prepare software for growth?

A system scales when important workflows continue to meet agreed response-time, error-rate, and cost targets as demand rises. Establish that with measurements and tests, not assumptions about a framework, hosting plan, or AI-generated code.

AJM Softwares · Technical note

Define what growth means

Describe demand in terms the business can plan for: active users, concurrent requests, data volume, and the busiest operations. Agree acceptable response times, error rates, availability expectations, and operating costs for those workloads.

Performance describes how quickly a system responds at a given load; scalability describes how its capacity and behaviour change as load grows. Reliability concerns whether it performs its intended work consistently and recovers from faults. Improving one does not prove the others.

Measure the complete request path

Instrument important user journeys through the application, database, and external services. Track throughput, latency percentiles, error rates, and resource pressure such as CPU, memory, slow queries, database connections, and dependency delays. Averages alone can hide slow requests.

Exercise representative journeys with synthetic or sanitised data in an environment close to production. Increase concurrency and request volume through expected peaks and short bursts. Set acceptance criteria before each run and identify which component first misses its target.

Fix measured constraints first

Profile the application and inspect slow database queries before changing its architecture. In PostgreSQL, use EXPLAIN to inspect query plans; EXPLAIN ANALYZE executes a query, so measure it with read-only queries or in a safe test environment. Add indexes for demonstrated access patterns; indexes use storage and add work to writes. Keep result sets bounded with pagination and watch for repeated per-row queries. Test concurrent writes against the data rules they must preserve.

Pool database connections where the deployment model requires it, and monitor both client and database connection limits. Cache repeated reads only when measurements justify the added complexity, with an explicit policy for data freshness. Read replicas can add capacity for read heavy workloads, but they are read only and asynchronous, so some reads may lag recent writes. Move slow work to a background queue only when it can safely run outside the user request and the chosen platform supports it. Queues can smooth bursts, but they do not increase a downstream service’s capacity. Bound consumer concurrency and slow or pause consumption when a dependency is saturated; make retries safe for repeated deliveries.

Choose architecture and hosting for the workload

Start with a clear, modular application that the team can deploy and maintain. Split it into services when independent scaling, fault isolation, or team ownership justifies the extra network calls, monitoring, and deployment work. No framework or AI coding tool sets a capacity target for the finished system.

Vertical scaling adds resources to an instance; horizontal scaling adds instances. Horizontal growth can expose assumptions about in-memory state and move pressure to the database or an upstream service. Check that each dependency can handle the additional concurrency before increasing application capacity.

Review current runtime and plan limits, database capacity, storage, regions, quotas, and pricing. Cloudflare Workers and Vercel Functions have different execution environments and constraints that can vary by runtime and plan. A hosting change or plan upgrade will not correct an inefficient query or unbounded workload.

Test changes and keep observing

Compare changes against the same workload and acceptance criteria: response-time percentiles, errors, database load, resource use, and cost. Test timeouts, throttling, dependency failures, retry behaviour, and what happens when a queue or connection pool reaches capacity. Only run load tests against systems and services where you have permission.

After release, compare production measurements with the baseline, alert on user-visible failures and resource saturation, and rerun targeted tests after significant changes. Record capacity assumptions and revisit them as usage and business needs change; scalability is an ongoing engineering concern, not a one-time certification.

Discuss your project