When a Project Counts as High-Load
Load isn't just about visitor numbers. A project becomes "heavy" when several factors hit it at once: lots of users, a large catalog or database, constant data exchange with other systems, and background jobs running around the clock.
Typical signs: the site is fast at night and slow during the day, crashes during sales, the admin panel takes minutes to load, product imports slow down the storefront, and every new feature breaks something elsewhere.
The problem is rarely solved by simply buying a more powerful server. More often, the real cause is a single slow database query, a missing cache, or an external service that responds slowly and drags the whole system down with it.
What Support Includes
The scope depends on the project, but support typically covers:
- Speed and stability. We regularly check how fast key pages and services respond and investigate every slowdown.
- Database. We track slow queries, table growth, and indexes, and set up read replicas when the primary database can't keep up.
- Background processes. We make sure imports, email sends, and accounting system sync don't take resources away from shoppers.
- Infrastructure. Load balancing across servers, Nginx, PHP, or Node.js configuration, and headroom for growth.
- Development. New features, library updates, and gradual refactoring of problematic code.
So you don't hear about outages from your customers, support is usually paired with monitoring and alerts.
Who Needs It and Who Doesn't
The service makes sense for large online stores and marketplaces, portals with user accounts, subscription-based online services, and systems that partners access via API. In other words, anywhere a minute of downtime or a slow page costs real money.
If you have a corporate website or a small store that runs reliably, dedicated high-load support is most likely unnecessary. Standard support with updates and bug fixes will do, and we'll tell you so honestly on the first call.
Optimize, Upgrade the Server, or Scale Out
When a system can't keep up, there are three paths, each with its own pros and cons.
- A more powerful server. The fastest fix, often with immediate results. But infrastructure costs go up, and the underlying cause of the slowdown doesn't go away.
- Code and database optimization. Takes analysis and developer time, but eliminates the root cause. Often the system can then handle more on the same resources.
- Multiple servers. Load is spread across several application instances, with the database, cache, and search running separately. This gives you room for years of growth but adds complexity, and the system needs people who know how to run it.
We usually combine approaches: first we clear out the obvious bottlenecks, then plan scaling once the data shows it can't be avoided.
How We Prepare for Peak Periods
A sale, a major ad launch, or a busy season is when the system gets the most visitors and when an outage costs the most. So we prepare well in advance, not the day before.
- Together with you, we estimate expected visitors and orders and test that load on a staging copy.
- We reinforce the weak spots the test uncovers and add resources temporarily if needed.
- We move heavy background jobs to overnight hours and agree not to deploy major changes during the promotion.
- We agree on who from the team is on call during the peak and what we'll do if something goes wrong.
What to Prepare Before We Start
- access to servers, the code repository, and hosting or cloud dashboards;
- a list of business-critical flows: checkout, payment, account login, warehouse sync;
- a list of integrations and external services the system exchanges data with;
- incident history: when outages happened, what preceded them, and how they were resolved;
- upcoming plans: expected sales, ad campaigns, expansion into new markets.
If there's no documentation, that's normal: most large projects run without it. We'll build the picture we need during the audit.
How We Measure Results
At the start, we agree on metrics and track against them going forward. These typically include response time for key pages, error counts, frequency and duration of outages, background process speed, and system behavior under peak load.
No system never goes down, so we don't promise uninterrupted uptime. Our goal is different: fewer outages, shorter outages, and root causes that don't come back.
Common Mistakes on Large Projects
- Adding server resources every time something slows down without looking for the cause.
- Running heavy product imports or report generation during business hours on the same database shoppers are using.
- Deploying changes manually straight to the production server, with no staging copy and no way to quickly roll back.
- Rewriting everything from scratch instead of gradually improving the most problematic parts.
- Preparing for a sale at the last minute, when any change is already risky.
What Affects the Cost of Support
- System size and complexity: how many services, databases, integrations, and background processes.
- State of the code and infrastructure: whether there's a staging environment, automated deployment, monitoring, and documentation.
- Required response time: business hours only, or after-hours on-call coverage too.
- Development scope: stability only, or new features as well.
- Where the project runs: your own servers, rented servers, or the cloud.
We usually start with an audit and then propose an ongoing engagement with a transparent scope of work.
FAQ
Will you take on a project built by another team? Yes, that's common for large systems. We first get to know the code and infrastructure, and only then make changes.
Do we need to move to the cloud? Not necessarily. The cloud is convenient when load fluctuates a lot, but many large projects run well on rented servers. We decide after analysis.
Can the system be sped up without stopping sales? Yes. We test changes on a staging copy and roll them out to production servers in stages, during the lowest-traffic hours.
What if the system is already going down? Contact us. In that situation, we first help restore service, then find the cause and propose how to prevent it from happening again.
Why Promodex
We've been building and supporting websites since 2015 and have 750+ projects behind us, so we know how system requirements change as a business grows. Your project is handled by our in-house team, which never outsources the work, so your code and infrastructure don't have to be split between different contractors. You always know exactly what we're doing, why, and what it costs.
