E-commerce order platform
Meridian Retail is an online retailer. Black Friday traffic peaks at 10× normal, checkout must survive order surges, and the team wants to modernize the order pipeline that currently processes everything through a single shared database and an in-house queue.
The company is a classic case for the full Wahab Waypoint journey: capture the domain, evaluate the right event backbone, and check the existing design before committing.
Step 1 · Learn the domain
In Domain Context Learner, Meridian captures:
| Prompt | Answer |
|---|---|
| Domain | E-Commerce & Retail |
| Qualities that matter | Scalability, Resilience & uptime, Cost control |
| Data volume | High |
| Real-time needs | High — order status and inventory must update live |
| Integration complexity | Complex — payments, inventory, fulfillment, loyalty |
| Sensitive data | Cardholder data (PCI) |
Saving this profile pre-tunes Architect and Reviewer for a business where scalability, resilience, and cost lead the ranking — and where compliance must carry real weight because cardholder data is involved.
Step 2 · Evaluate the architecture
In Architect, Meridian opens the E-Commerce Order Platform scenario. The priority sliders arrive pre-tuned from the profile: scalability, reliability, and cost efficiency weighted high, with compliance raised for PCI.
Architect evaluates all ten reference architectures. The conversation typically comes down to the event-broker patterns:
| Architecture | Why it ranks well here | Watch out |
|---|---|---|
| Apache Kafka | Ordering and replay, strong reliability, scales with peaks | Operational overhead; needs care to run well |
| Amazon EventBridge | Simple event routing between many order-related services | Less replay control than a log |
| Amazon SQS | Simple, reliable queueing for decoupling order steps | Weak ordering guarantees outside FIFO |
| RabbitMQ | Familiar broker with flexible routing | Operational tuning for 10× peak bursts |
With Meridian's sliders, the event-log patterns (led by Apache Kafka) tend to rise to the top: the combination of per-partition ordering for order events, durable replay for reprocessing, and reliability during peak traffic outweighs the added operational simplicity of a managed queue.
What-If tip: if Meridian later decides operational simplicity matters more than replay, one slider move visibly reshuffles the ranking — a useful artifact for the platform decision review.
Step 3 · Review the design you have
Before the migration, Meridian reviews the current stack in Reviewer — a single monolith database feeding an in-house queue — against the same scenario and domain-adjusted requirements. The verdict is blunt:
| Finding | Why |
|---|---|
| Low fit on scalability | One shared database and one queue are the bottleneck at 10× peaks |
| Low fit on replay | No durable log to re-process order events |
| Low fit on ordering at scale | Single in-house queue cannot keep per-order ordering under load |
| Strength: compliance posture | Existing PCI controls map cleanly to the target design |
The gaps map almost one-to-one onto the Architect recommendation, which turns the review into a migration checklist: introduce a durable, partitionable event backbone, split the shared database behind it, and preserve the existing compliance controls.
Another angle on the same journey: the media event pipeline example →