A gifting retailer had built a catalogue business on top of a delivery promise it could not verify. Customers chose a bouquet, entered an address at the final step, and discovered only then that nobody could deliver it that day. ELIVTECH rebuilt the platform on Shopware so that serviceability, vendor capacity and delivery slot are resolved at the first interaction rather than the last, and moved the whole system onto AWS infrastructure that absorbs occasion peaks without manual intervention.
The client operates a marketplace of independent florists and gift vendors fulfilling same-day orders across a wide pin-code footprint. Delivery feasibility depended on a nightly vendor coverage file, so the storefront routinely accepted orders that no vendor could serve, and operations absorbed the failure by phone. Occasion peaks compounded the problem: traffic arrives in a few sharp hours around a handful of dates, and the previous infrastructure was sized by hand ahead of each one. ELIVTECH rebuilt the storefront on Shopware with a serviceability layer that gates the catalogue by delivery address, a slot-and-capacity engine that reserves vendor time at the moment of add-to-cart, and an autoscaling AWS deployment defined in code.
At a glance
The challenge
A same-day promise made at the top of the funnel and tested only at the bottom of it.
Serviceability discovered too late
Delivery coverage was checked once, at the shipping step. Customers spent time choosing a gift, personalising a message and entering payment details before learning their pin code had no vendor for that day. Operations then handled the fallout as a support conversation rather than a product decision.
Delivery slots without capacity
Time slots were presented as static options with no link to vendor workload. Several orders could claim the same florist's morning window, and the conflict surfaced only when the vendor opened the day's queue. Rescheduling a dated gift after the occasion has passed is not a recoverable outcome.
Peaks handled by hand
Occasion traffic concentrates into a few hours around a small number of dates. Infrastructure was scaled up manually before each one and scaled down afterwards, which depended on someone remembering and on the estimate being right. Checkout was the first component to degrade when it was not.
Vendor catalogues drifting apart
Each vendor maintained product data in its own format and cadence. The same bouquet appeared under different names, sizes and images depending on the fulfilling florist, so merchandising could not present a coherent range and search could not group equivalent products.
Occasion catalogues rebuilt manually
Seasonal ranges were assembled by hand each cycle as duplicated categories and hard-coded landing pages. The work repeated every occasion, arrived late, and left stale pages behind that continued to rank and take traffic after the date had passed.
No path to a safe release
Servers were configured by hand and drifted from one another. There was no reliable way to reproduce production for testing, so changes were deferred until a quiet window, which meant fixes discovered during an occasion peak had to wait until after it.
Our solution
Serviceability first, capacity reserved with the cart, and infrastructure that scales without a person in the loop.
Discovery and Fulfilment Modelling
Three weeks mapping how a same-day gift actually reaches a recipient: vendor coverage by pin code, cut-off times per slot, product classes each vendor can prepare, and the substitution rules that apply when a specific stem is unavailable. This produced a single fulfilment model that the catalogue, cart and vendor portal all resolve against, replacing rules that had lived in spreadsheets and habit.
Shopware Core with a Serviceability Gate
Shopware was rebuilt with delivery context established at entry. The recipient pin code and date are captured before browsing and held in the session, and every listing, product page and cart operation resolves against that context. Products a customer cannot receive are filtered out rather than shown and refused, so the catalogue reflects a promise the network can keep. Coverage lookups resolve against a pin-code table cached in Redis and refreshed as vendors change their footprint, which keeps the gate cheap enough to apply on every listing request rather than only on the first.
Slot Capacity and Vendor Allocation
A capacity service holds vendor slot inventory in MySQL with a soft reservation taken at add-to-cart and confirmed at payment. Reservations expire on a timer so abandoned carts return capacity to the pool. Allocation weighs vendor proximity, product class capability and current load, and falls back to the next eligible vendor when the preferred one reaches its ceiling. Reservation rows are locked per vendor and slot so two concurrent carts cannot both claim the last unit, and the expiry sweep runs as a queued job rather than a request-time check.
Elasticsearch Discovery and Autoscaling AWS Delivery
Occasion, recipient and sentiment tags were added to the search index so seasonal ranges are queries rather than duplicated categories. The platform runs on containers behind an application load balancer with autoscaling driven by queue depth and request latency, all defined in Terraform, with Redis absorbing catalogue and session read pressure during peak hours.
Technology stack
Results
Measured across a full occasion peak on the new platform against the previous cycle.
Before and after: platform engineering measures
- Delivery coverage checked once, at the shipping step
- Slots offered with no link to vendor capacity
- Infrastructure scaled by hand ahead of each occasion
- Vendor catalogues ingested nightly in vendor-specific formats
- Occasion ranges built as duplicated categories and static pages
- Servers configured manually and drifting apart
- Releases deferred to quiet windows outside trading hours
- Delivery context established at entry and enforced throughout
- Capacity soft-reserved at add-to-cart, released on expiry
- Autoscaling driven by queue depth and request latency
- Vendor feeds normalised into one catalogue contract on ingest
- Occasion ranges expressed as saved search queries
- Environments reproduced from Terraform definitions
- Releases ship during trading hours with automated rollback
Project timeline
Discovery and Fulfilment Modelling
Vendor coverage and cut-off mapping, product class capability matrix, substitution policy, peak traffic profiling from historical logs, and the target Shopware and AWS architecture.
Platform and Infrastructure Foundation
Shopware installation on containerised AWS infrastructure defined in Terraform, MySQL schema for vendors, coverage and slot capacity, Redis caching, queue-backed background processing, and the deployment pipeline with automated test gates.
Serviceability and Capacity Engine
Pin-code coverage resolution with caching, delivery context propagation through listing and cart, soft reservation with timed expiry, vendor allocation and fallback logic, and the vendor portal for capacity and blackout management.
Catalogue Normalisation and Discovery
Vendor feed ingestion into a single catalogue contract, duplicate grouping across vendors, Elasticsearch index design with occasion and recipient tagging, and merchandising controls that let seasonal ranges be configured rather than built.
Peak Readiness and Cutover
Load testing shaped to real occasion traffic curves, autoscaling policy tuning, CloudWatch dashboards and alerting on queue depth and reservation failures, then a staged cutover with the previous storefront retained until the first peak passed cleanly.
Key takeaways
What shaped the engineering decisions
- Gate the catalogue, do not validate the checkout: Showing everything and refusing at the end was rejected because it spends the customer's effort before delivering the bad news. Resolving delivery context at entry means the catalogue only ever offers what the network can fulfil.
- Reserve capacity at intent, not at payment: Confirming slots only on payment was rejected because the gap between add-to-cart and completion is exactly where two customers claim the same vendor window. A soft reservation with timed expiry holds capacity without leaking it to abandoned carts.
- Normalise vendor data on ingest: Vendor feeds are reconciled to one catalogue contract as they arrive rather than at read time. Search groups equivalent products across vendors, and merchandising works against a coherent range instead of per-vendor variants of the same bouquet.
- Make occasions queries, not categories: Tagging products by occasion, recipient and sentiment in the search index turned seasonal ranging into configuration. Ranges go live without a deployment and retire on schedule instead of leaving stale pages behind.
- Scale on the signal that actually leads: CPU-based autoscaling reacts after checkout has already slowed. Scaling on queue depth and request latency responds to the pressure that matters during a short, sharp occasion peak.
- Rehearse the peak, do not predict it: Load tests were shaped to real occasion traffic curves rather than uniform load, which exposed reservation contention that steady-state testing would not have surfaced until the day it mattered.
Want results like these?
Let's discuss how ELIVTECH can drive measurable outcomes for your business.
Start your project