Scalable systems for tomorrow.

Define growth in concrete terms

‘The system must scale’ is not yet a testable requirement. Describe the expected load and required response times instead. How many operations happen at once? How large is the data? Is usage steady or concentrated in short bursts? Which tasks can run in the background?

Placing an order, importing data and generating a report have different requirements. Treating them alike may mean optimising the wrong area. Identify the critical user journeys and what overload would look like in each one.

Clear boundaries before distributed complexity

A well-structured, shared application server can be a sensible starting point for many projects. The key is to separate business domains and responsibilities clearly. Well-defined modules are easier to change independently later.

Splitting a system into many services creates additional work: network failures, distributed debugging and inconsistent data all need to be managed. The number of services is not what matters. Architecture should address problems that actually exist or can reasonably be expected.

Plan APIs and background tasks

APIs need clear contracts: what data is expected? Which response means success? What happens after a timeout or a repeated request? For bookings and other write operations in particular, retries must not accidentally perform the same operation more than once.

Long-running tasks can often be separated from the immediate user request through a queue. Asynchronous communication can decouple components and absorb spikes in demand; Microsoft describes several messaging patterns for this. It does not remove the need to plan for backlogs, failed messages or duplicate events.

Further reading: Microsoft: Asynchronous messaging options ↗

Measure bottlenecks before rebuilding

A bottleneck often lies in one specific place: a slow database query, an external API or a task performed unnecessarily often. Load tests using realistic workflows make these limits visible. The number of simultaneous connections alone says little about a complete business process.

Measure response times, error rates and resource usage together. Logs should let you trace an operation through its stages without recording unnecessary confidential information. This helps distinguish whether more computing power will help or whether the process itself needs to change.

Treat failures as part of operations

Even a well-designed system can fail. Decide who detects an incident, how it is investigated and how a previous working version can be restored. Backups are dependable only once restoration has been tested in practice.

Scalability also has an economic side. More infrastructure brings additional costs and operational work. For every expansion, identify the specific capacity limit being raised and its effect on running costs and maintainability.

• Specify load, critical workflows and response times.
• Keep responsibilities and APIs clear.
• Measure bottlenecks under realistic load.
• Consider monitoring, recovery and costs together.