---
title: "Real-life scenario: AtlasMarket"
chapter: "29"
---

# 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

| Term | Plain meaning |
|---|---|
| AD / ADL / ADF | Architecture description / language / framework |
| ADR | Architecture Decision Record |
| API / RPC | Application interface / remote procedure call |
| ATAM | Architecture Tradeoff Analysis Method |
| BFF | Backend for a Frontend |
| CAP | Consistency, availability, partition-tolerance trade-off framing |
| C4 | Context, Container, Component, Code architecture views |
| CDN / WAF | Content delivery network / web application firewall |
| CDC | Change Data Capture |
| CQRS | Command Query Responsibility Segregation |
| DDD | Domain-Driven Design |
| DLQ | Dead-letter queue/channel |
| DRY / KISS / YAGNI | One knowledge source / keep simple / avoid speculative work |
| ESB / SOA | Enterprise service bus / service-oriented architecture |
| FaaS / PaaS / IaaS / SaaS | Function/platform/infrastructure/software as a service |
| HATEOAS | Hypermedia controls guide REST clients |
| IdP / IAM | Identity provider / identity and access management |
| MTBF / MTTR | Mean time between failure / to restore or repair |
| NFR | Non-functional or quality requirement |
| PII | Personally identifiable information |
| RPO / RTO | Acceptable data loss / recovery time objectives |
| SAGA | Long-running distributed transaction with explicit steps and compensation |
| SLI / SLO / SLA | Indicator / internal objective / contractual agreement |
| SOLID | Five object/module design heuristics |
| STRIDE | Spoofing, tampering, repudiation, disclosure, denial, elevation threats |
| SysML / UML | Systems / Unified Modeling Language |
| TTL | Time to live |
| Two-phase commit | Atomic commit protocol across participants |
| Zero trust | Verify each access using identity, context, and policy |

## Official and primary references

- [ISO/IEC/IEEE 42010:2022](https://www.iso.org/standard/74393.html)
- [ISO/IEC 25010:2023](https://www.iso.org/standard/78176.html)
- [C4 model](https://c4model.com/)
- [C4 diagram checklist](https://c4model.com/diagrams/checklist)
- [arc42](https://arc42.org/)
- [SEI quality attributes](https://www.sei.cmu.edu/library/reasoning-about-software-quality-attributes/)
- [Azure architecture styles](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/)
- [Cloud design patterns](https://learn.microsoft.com/en-us/azure/architecture/patterns/)
- [OWASP Secure by Design](https://owasp.org/www-project-secure-by-design-framework/)
- [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/)

## 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.