When a business needs a high-load system: signs, scenarios and the first step
A highly loaded system is not synonymous with a “very popular website” and is not a reason to immediately rewrite the product with microservices. Usually the question arises earlier: the personal account responds unstably during business hours, ordering slows down during a promotion, the API cannot cope with partner requests, and the team no longer understands what will happen after the next growth.
In this situation, it is more useful not to choose a technology based on the trend, but to analyze critical scenarios. If you need a technical plan with risk assessment and implementation, check out the service development of high-load systems. Below are the signs by which you should start such an analysis.
Highload starts with critical scenarios, not the number of users
Two services with the same audience may have completely different requirements. A corporate portal for several thousand employees works smoothly on one application, and a marketplace with a smaller number of visitors loses orders if hundreds of users simultaneously reserve one product.
What is important for assessment is not the abstract “users per day”, but the answers to the questions:
- what actions cannot be interrupted: payment, order, login, price calculation, synchronization of balances;
- what events create peaks: advertising campaign, opening of sales, reporting period, data import;
- what answer the user is willing to wait for and what percentage of errors is acceptable;
- what should happen when overloaded: queue, restriction of some functions, retry or manual script;
- What external systems does the operation depend on: 1C, payment gateway, telephony, warehouse, CRM, partner API.
Such a list turns the conversation “the site is slow” into verifiable technical requirements. He also helps prepare the correct load testing of a web application: you need to test not a random stream of requests, but real chains of actions.
Five signs that it’s time to reconsider architecture
1. Not everything is slow, but the most expensive actions for business
The main page can open quickly, but the manager is waiting for the upload, the client cannot confirm the order, and the operator manually corrects the data after the exchange. In such cases, you need to measure the entire path: application, database, queue, external API and background tasks. Optimizing the interface alone will not solve the problem on the server.
2. Demand peaks become an incident every time
If the team knows in advance the date of a sale, the launch of a new tariff, or a mass mailing, but is still on duty “just in case,” the system lacks a predictable load contour. We need test scenarios, target indicators, resource reserves and clear actions in case of degradation.
3. One operation blocks the others
A common reason is a long synchronous process. For example, after payment, the application waits for a response from the accounting system, and if it fails, the user repeats the request. This may include a task queue, idempotency of operations, constrained retries, and visible processing status to the user.
4. The database has become the only pain point
Table growth, heavy selections, lack of indexes, competing records and reports during business hours create delays even when the application server is free. Sometimes it is enough to reconsider the queries and data model. Sometimes you need a cache, reading from a replica, or a separate loop for analytics. The decision depends on the specific scenario, not on the popularity of the tool.
5. Releases are becoming more and more dangerous
When changing one feature could break integration or lock data, the team starts releasing updates less frequently. For a growing product, reversible releases, version-compatible migrations, post-release monitoring, and a clear rollback plan are important.
Where to start: audit, modernization or new platform
Not every product needs a new backend. In practice, three different trajectories are useful.
Load audit suitable if the cause of the problems is not obvious. It provides a map of critical scenarios, measurements and a priority list of changes. This is a good first step to protecting your budget from accidental overwriting.
Phased modernization needed by a running system that has specific limitations: heavy queries, synchronous exchanges, unmanaged background tasks, or an infrastructure without observability. The goal is to eliminate bottlenecks without stopping the product.
New platform justified when the business model and integration outline no longer fit within the old boundaries. Then they first design the domain model, API, data and release order, rather than starting with choosing a framework.
The transition from monolith to services can be part of any of these trajectories, but does not have to be. In a separate article we will analyze when microservices really help, and when is it better to develop a modular monolith.
What should the team have left after the first stage?
A good technical analysis ends not with a presentation, but with working artifacts:
- a list of critical scenarios with availability and response time targets;
- diagram of current dependencies: application, data, integrations, background processes;
- measurement results and explanation of bottlenecks;
- change plan with implementation order and risks;
- approach to releases, monitoring and incident response.
This format is applicable to both a new product and an existing system. In the case Road to the Dream The server circuit unites the store, API, integrations, Redis, queues and the administrative part - it is these connections that are important to sort out before scaling.
How to make a decision without unnecessary complexity
Start with one critical user journey. For example: “a user places an order”, “a partner submits a request via API” or “a manager creates an offer”. Record normal execution times, workload peaks, and the consequences of an error. Then test that path through your application, database, and external dependencies.
If the technical team lacks time or independent perspective, highload development page the context of the product can be described. We will help you determine whether an audit, specific optimization or architectural step is needed, and prepare the composition of the first iteration.
FAQ
How many requests per second is considered highload?
There is no universal number. The load is determined not only by the number of requests, but also by their cost, concurrency, work with data and dependencies. A few heavy operations can be more dangerous than thousands of simple queries.
Should I use Kubernetes and microservices right away?
No. They solve specific operational and scaling problems, but add complexity. First you need to understand the requirements for reliability, releases and independent scaling of parts of the product.
Is it possible to conduct an audit without access to the source code?
Some problems can be seen in metrics, logs, infrastructure and test results. A precise optimization plan usually requires controlled access to code and data, but the amount of access is determined at the start of work.