Real-life scenario: AtlasMarket global commerce modernization

AtlasMarket operates a marketplace in twelve countries. Its ten-year-old application shares one database, has six-hour releases, duplicate charges during provider timeouts, oversold stock during campaigns, and no reliable way to trace an order across support, warehouse, and finance.

Outcomes and measurable scenarios

• a customer sees a confirmed order within two seconds at p99 during 5× demand;
• the system never creates two charges for one payment intent;
• inventory never confirms more units than are available;
• a zone failure loses no confirmed order and recovers traffic within five minutes;
• support can trace one order without reading raw personal data;
• a normal change reaches production in one hour with independently reversible rollout;
• a regional payment or recommendation outage degrades checkout safely.

Context and domains

The context includes customer web/mobile clients, seller portal, identity provider, payment providers, tax, fraud, warehouse, carrier, notifications, analytics, finance ledger, support, privacy operations, and human fulfillment.

Domain discovery produces Catalog, Pricing, Basket, Ordering, Inventory, Payment, Fulfillment, Customer, Seller, and Finance bounded contexts. Ordering owns the order lifecycle; Inventory owns available-to-promise; Payment owns payment attempts and provider idempotency; Finance owns immutable accounting.

Target architecture

Begin with a modular monolith for Catalog, Pricing, Basket, Ordering, and Customer. Extract Payment and Inventory because they need strict isolation, specialized scaling, data ownership, and independent risk controls.

Clients → CDN/WAF → BFF/API gateway → commerce application

Ordering → Inventory reservation API

Ordering → transactional outbox → event log → Payment/Fulfillment/Analytics

Payment orchestrator → provider adapters

Operational stores → CDC/curated events → analytical lakehouse

Each tenant cohort runs in a deployment stamp containing application workers, cache, message partitions, and database partitions. The control plane assigns cohorts and manages rollout. A regional ledger remains authoritative for financial facts; cross-region replication has explicit recovery semantics.

Critical order flow

1. Client submits order with idempotency key and basket version.
2. Ordering validates price snapshot and asks Inventory for a timed reservation.
3. Ordering commits PendingPayment plus an outbox record atomically.
4. Payment saga creates a provider intent using the order payment key.
5. Provider webhook is authenticated, deduplicated, and reconciled.
6. PaymentAuthorized moves the order to Confirmed and starts fulfillment.
7. Expiry or permanent failure releases inventory; uncertain payment enters reconciliation rather than blind retry.

Data and consistency

Each service owns its schema. No cross-service joins occur on the write path. Read models compose order status for customers and support. Events have stable identity, owner, schema, partition key, privacy classification, and retention. Outbox/inbox handles at-least-once delivery. Daily reconciliation compares orders, payment provider records, inventory reservations, and finance entries.

Resilience and capacity

End-to-end checkout has a two-second deadline. Recommendation and nonessential enrichment are shed first. Remote calls have allocated timeout and retry budgets. Payment retries require stable provider idempotency. Bulkheads isolate providers and tenant stamps. Queues absorb campaigns but enforce backlog-age objectives. Restore, zone loss, provider outage, broker pause, duplicate webhook, and poison message are exercised.

Security and privacy

Trust boundaries are shown on data-flow diagrams. User identity terminates at the edge but every domain authorizes its resource. Workload identity and narrow-audience tokens protect service calls. Card data is tokenized; secrets use managed rotation; logs exclude payment and personal values. Retention, export, and deletion propagate to caches, projections, search, and analytics. STRIDE and business-abuse analysis cover price manipulation, seller fraud, inventory hoarding, replay, webhook forgery, and cross-tenant access.

Observability and delivery

Request, trace, order, saga, payment intent, message, tenant, and stamp identifiers preserve causality without logging PII. SLIs measure checkout success/latency, duplicate charge invariant, oversell invariant, queue age, reconciliation gaps, stamp saturation, and cost per order.

The migration uses a strangler route, anti-corruption layer, CDC-backed parity projections, shadow reads, cohort canaries, expand-contract schema changes, and explicit rollback. Every extracted capability has entry and exit criteria.

Architecture package

• ISO 42010 stakeholder/concern map and viewpoint definitions;
• C4 context, container, component, dynamic, and deployment views;
• domain/context map, critical sequence and state models;
• data ownership, lineage, retention, and consistency matrix;
• quality-attribute scenarios and ATAM/risk results;
• threat model and control-to-evidence map;
• capacity model, SLOs, dashboards, game-day and restore evidence;
• ADRs for modular monolith, extraction, messaging, consistency, cells, and regions.

Glossary and abbreviations

Official and primary references

• ISO/IEC/IEEE 42010:2022
• ISO/IEC 25010:2023
• C4 model
• C4 diagram checklist
• arc42
• SEI quality attributes
• Azure architecture styles
• Cloud design patterns
• OWASP Secure by Design
• OWASP ASVS

Final Feynman challenge

Trace one AtlasMarket order from purpose, stakeholder and quality scenarios through context, domain boundaries, APIs, data ownership, consistency, deployment, failure, security, telemetry, delivery, evaluation, and evolution. At each boundary explain what is owned, what can fail, and what evidence proves the design claim.