Context
A UAE-based global gifting and hamper delivery business operated a high-traffic e-commerce platform where seasonal campaigns created significant pressure across the application, database, and infrastructure layers. During peak festival periods, the platform experienced sharp increases in traffic, order volume, and transactional activity within short operational windows. Availability and responsiveness were directly tied to revenue continuity, customer experience, and fulfillment operations. The platform had evolved on top of a legacy monolithic architecture and relied heavily on vertically scaled infrastructure to absorb increasing demand.
The Root
- Legacy Platform Decomposition
- Distributed Catalogue Read Model
- Horizontal Scaling Architecture
- Distributed Caching Strategy
- Peak-Load Resilience Testing
The Challenge
The platform was not originally designed for efficient horizontal scaling. Core workloads were tightly coupled within a single application and relational database environment, including storefront catalog traffic, customer data, orders, payments, product metadata, and operational workflows. As seasonal demand increased, several limitations became visible:
- Heavy database contention under high storefront traffic
- Slow queries and inefficient access patterns
- Limited distributed caching beyond local in-memory approaches
- Dedicated infrastructure without natural horizontal scaling behaviour
- Architectural boundaries that made independent scaling difficult
The organisation had historically relied on vertical infrastructure scaling during peak periods. This increased cost while still leaving availability and scaling risk during seasonal traffic spikes.
The challenge was to reduce peak-season operational risk while moving the platform toward a more scalable and cost-efficient operating model without disrupting active business operations.
What Was Done
The work focused on separating scale-heavy read traffic from transactional operations while improving the platform’s ability to expand under load. Historical traffic and operational logs were analyzed to identify high-frequency access behavior, database bottlenecks, and infrastructure stress points.
The relational database environment was profiled to isolate slow queries, inefficient joins, indexing gaps, and schema-level bottlenecks. Transactional domains such as orders, payments, and customer data remained within the primary relational system to preserve consistency, integrity, and auditability.
High-volume storefront and catalog read workloads were separated into a distributed read-optimized model designed to scale independently from transactional operations. This reduced pressure on the primary database layer and improved storefront scalability during high-demand periods.
Local in-memory caching was replaced with a distributed caching strategy better suited for multi-instance application scaling. The deployment setup was restructured to support threshold-based scaling mechanisms on dedicated hosting infrastructure. This allowed the platform to expand during high-demand periods while reducing unnecessary infrastructure usage outside seasonal peaks.
Before production rollout, load and stress testing validated application behavior, database resilience, and infrastructure scaling under sustained high-traffic conditions.
The objective was to expose scaling limits before peak seasonal events, not during them.
Outcome
The platform remained operational throughout peak seasonal traffic periods without customer-facing interruption. The broader changes also created a stronger foundation for ongoing platform evolution:
- Improved scalability under high-demand conditions
- Reduced pressure on the transactional database environment
- Clearer separation between transactional and storefront workloads
- Better infrastructure utilisation during non-peak periods
- A more maintainable and extensible platform foundation
Most importantly, the platform moved away from relying primarily on expensive vertical scaling toward a more operationally resilient and horizontally scalable model.
What This Represents
At scale, e-commerce reliability is rarely just an infrastructure problem. It becomes a systems design problem involving architecture boundaries, data access patterns, caching strategy, deployment behaviour, and the ability to evolve legacy systems without disrupting live business operations.
Experiences like this shape how Rootstone approaches scalability, operational continuity, and long-term platform sustainability under real-world business pressure.
Note: This example reflects founder experience gained through prior engineering and technology leadership roles before Rootstone. It is not presented as work delivered by Rootstone as a company. Client names and identifying details have been omitted to preserve confidentiality, while focusing on the type of systems, constraints, and decisions that shape Rootstone’s approach today.
