Every year, the same scenario repeats itself: October arrives, e-shops start planning their Black Friday campaigns, and suddenly someone asks the question: "Will our servers be able to handle it?" There's nothing worse than investing millions in a marketing campaign and then watching your infrastructure collapse under the onslaught of customers in November.
"It's better to have performance and not need it than to need it and not have it," says Ondřej Flídr, senior infrastructure administrator at vshosting.
Plan based on data, not feelings
Hard numbers are the basis of any preparation for the season. If you've been running an e-shop for a long time, you have data from previous years at your disposal – year-on-year traffic growth, number of orders, impact of individual campaigns. If you don't have the data, start collecting it now.
Practical tip: It's better to count on ten times the normal traffic than on optimistic estimates. "I saw an e-shop that went down just because it couldn't handle sending out emails," recalls Ondřej Flídr, referring to one case where an undersized solution failed.
When vertical scaling is no longer enough
If your e-shop runs on a single server and is approaching its limits, you have several options. The fastest is vertical scaling—adding a more powerful processor, more memory, or a faster disk. The advantage is the speed of implementation and the fact that there is no need to change the application.
"At vshosting, we always have hardware in stock, so the server is simply shut down at night, upgraded, and running with new hardware in half an hour," explains Václav Skála. The problem arises when you reach the limits of available hardware or when the software cannot effectively utilize additional resources.
Software limitations as an obstacle
Adding more power does not always help. Redis, for example, runs in a single thread, so adding more cores will not improve performance. Elasticsearch, on the other hand, cannot effectively use more than 32 GB of memory due to the way Java manages memory.
"I saw a case where an application used locking in memcachi with a key containing the entire URL. All requests for the same URL then waited in line behind each other," says Václav Skála, describing one of the problems where hardware scaling did not solve the application problem.
Short-term solution: Separation of roles
When one server is no longer sufficient and you cannot upgrade it further, there is a quick solution—separating the database onto a separate server. It's simple, fast, and requires minimal changes to the application.
"This will buy you about a year," warns Václav Skála. "When you need to separate other components, such as Elasticsearch, you'll only buy yourself an extra month."
The main disadvantage is reduced availability – instead of one server that can fail, you have two. And if either of them is down, nothing works.
Long-term solution: Cluster architecture
For e-shops that are growing in the long term, the best solution is to switch to cluster architecture. "If one server in the cluster goes down, nothing happens. If one server in a single setup goes down, your season is over," says Václav Skála, summarizing the main advantage.
Components of a modern e-shop cluster
1. Load balancers
- Entry point to the cluster with a public IP address
- SSL connection termination and load balancing
- Option to cache static files
- Often also VPN for secure access to the infrastructure
2. Application servers
- This is where the e-shop itself runs (PHP, Node.js, etc.)
- Must be stateless – save sessions to Redis, not to disk
- Can be easily scaled by adding more instances
3. Database servers
- Master-slave or multimaster replication
- Important: each server must be able to handle the traffic of the entire cluster
- Beware of replication delays under high load
4. NoSQL servers
- Redis for sessions and cache (ideally separate instances)
- Elasticsearch for search (separate from logging)
- Each component according to the needs of the e-shop
Testing at the limits
Load tests are absolutely essential and should include:
- Performance tests – verify how you handle a defined load
- Stress tests – show when the whole thing crashes
"It's better if it crashes now in the summer during testing than in December during live operation," adds Ondřej Flídr.
Don't forget about weak points outside the infrastructure
Even a perfectly prepared infrastructure can fail due to external factors:
- ERP system – can it handle thousands of orders per hour?
- Mailing services – antispam filters may block you during a sudden increase
- Payment gateways – do they have sufficient capacity for your campaign?
"Replication is fine. Until the master server goes down and the slave server can't keep up with replication and has old data," warns Václav Skála of another pitfall.
Practical tips for seasonal preparation
Databases and replication
- Use only InnoDB tables for MariaDB
- All tables must have a primary key
- Divide large operations into smaller parts (DELETE with LIMIT)
- Expect that replication repair will take one server out of service
Redis optimization
- Separate sessions from the application cache
- For sessions: no memory limit, with set expiration
- For cache: memory limit with automatic deletion of oldest data
- Consider KeyDB as a faster alternative to Redis
Elasticsearch specifics
- Do not allocate more than 32 GB of memory for Java heap. S
- tick to the limit of 20 shards per GB of memory.
- Separate search from logging into separate clusters.
Disaster recovery: When everything goes wrong
Even with perfect preparation, anything can happen—human error, a bug in an application, a data center outage.
Be prepared with:
- Backup scenarios, including a second location
- Regular backups with tested recovery
- Procedures for quick crisis resolution24/7 contact details for key suppliers
Checklist for seasonal preparation
✅ Data analysis – real estimates based on historical data, better to overestimate
✅ Load testing – performance, stress, with realistic usage scenarios
✅ Infrastructure – either vertical scaling or transition to a cluster
✅ External dependencies – verification of ERP, mailing, and payment gateway capacities
✅ Backup plans – including a second location and disaster recovery
Conclusion: Summer is the last time to prepare
Preparing your e-shop for the season is not just about technical infrastructure. It is an investment in peace of mind and the certainty that when you launch your biggest marketing campaigns in the fall, your infrastructure will be ready for success.
"When you separate the database, you buy yourself a year. When you separate other components, you buy yourself a month. But eventually, it will catch up with you," concludes Václav Skála. That's why it's better to use the summer months to invest in a cluster solution that will grow with your business.
If you are unsure whether your current solution can handle this fall season, now is the ideal time to contact us at: consultation@vshosting.eu and get enough time for thorough planning, testing, and any necessary adjustments before the critical months.