E-Commerce
E-commerce infrastructure
An architecture that scales for campaign periods, with cache and database tiers separated. Capacity is raised before the peak and reduced when it passes.
- Web, cache and database separated
- Tiered
- Campaign-period scaling
- Seasonal
- Low latency on order transactions
- NVMe
- Always-on protection
- DDoS
Why sites go down on campaign day
Outages in e-commerce stacks rarely come from total server capacity. The most common cause is the database becoming a bottleneck: when product listing, search and cart operations all load the same database, the connection pool fills and every request queues.
The second common cause is a missing cache layer, or one running as a single instance. Without a cache, every page view hits the database. With a single-instance cache, that instance failing dumps the entire load onto the database at once and the failure cascades.
The third is trying to scale on campaign day. Adding capacity is a planned operation; applying it once traffic has already climbed is both risky and too late. The right approach is to raise capacity ahead of the peak and lower it afterwards.
We build an architecture that treats these three separately: web tier, cache and database on separate servers with 10 Gbps private networking between them. Because the tiers scale independently, you can act precisely where the bottleneck forms.
- Web, cache and database tiers on separate servers
- Inter-tier traffic on the 10 Gbps private network, at no cost
- The cache layer made redundant through replication
- Capacity raised ahead of campaigns as a planned change
- DDoS protection runs continuously
Process
Preparing for a campaign period
- 01
Historical review
Which resource peaked and which queries slowed in previous campaigns — the Zabbix history shows it.
- 02
Capacity plan
How much each tier will grow is agreed in advance against the expected traffic increase.
- 03
Provision ahead
Capacity is raised before the peak begins; no changes are made on campaign day.
- 04
Post-period scaling
Once the peak passes, resources are scaled back — you don't pay for capacity you're not using.
Features
Architecture components
Web tier
Application servers, expandable horizontally by adding servers as load grows.
Cache tier
Redis for query results and session data, made non-single-point-of-failure through replication.
Database tier
A database on NVMe, with reporting load optionally routed to a read replica.
Security layer
DDoS protection, FortiGate rules and network-level separation of payment traffic.
Monitoring
Response time, database connection counts and cache hit ratio are tracked throughout the campaign.
Backup
Because losing order data is unacceptable, backup frequency is planned accordingly.
FAQ
Frequently asked questions
How far ahead should we scale up for a campaign?
Safest is a few days before the peak, so the change can be tested. That confirms the new capacity behaves as expected and avoids surprises on campaign day.
How is payment data protected?
Components carrying payment traffic are placed in a separate network segment with access opened only to defined sources. Obligations around storing card data depend on the payment platform you use, and we review that with you before deployment.
Our site is slow — will a bigger server fix it?
Usually not. Slowness typically comes from database queries, missing indexes or the absence of a cache layer. We first look at Zabbix metrics and the slow query log to locate the bottleneck; adding resources only helps when resources are genuinely the limit.
Our traffic is irregular — should we buy fixed capacity?
Irregular traffic is exactly where the flexible model pays off. Buying fixed capacity sized to the peak means paying for idle resources the rest of the year. Raising and lowering capacity by period makes more sense on both cost and risk.
More
Related pages
- RedisRedis and high-availability replicationReplicated Redis deployments for caching, session storage, queues and rate limiting. Persistence, eviction policy and memory monitoring configured.
- MySQL / MariaDBMySQL and MariaDB hostingManaged MySQL / MariaDB hosting with InnoDB tuning, connection pooling, utf8mb4 configuration and master-replica setup. NVMe storage and daily backups.
- DDoS ProtectionProtection against DDoS attacksAlways-on protection against volumetric, protocol and application-layer DDoS attacks. Edge scrubbing, anomaly detection and preservation of legitimate traffic.
- ScalingvCPU and RAM scalingIncrease your cloud server's vCPU and memory without a rebuild. Capacity planning driven by Zabbix metrics, planned maintenance windows and two-way scaling.
Let's plan your infrastructure together
Tell us what you need and we prepare a configuration and pricing specific to you. We don't sell fixed packages; we build the deployment, licensing and backup plan with you.