Distributed E-Commerce Platform
A production-oriented Azure reference architecture for a commerce backend that balances responsive checkout, inventory consistency, asynchronous processing, private connectivity, observability, and regional resilience without defaulting to Kubernetes complexity.
+ WAF→App Service
API + workers→Cosmos DB
+ Service Bus
Keep checkout responsive without making consistency vague.
The customer-facing API should acknowledge work quickly while downstream inventory, payment, shipping, and analytics can proceed independently. The design therefore keeps the synchronous path small, makes inventory reservation an explicit consistency boundary, and pushes long-running work into asynchronous consumers.
The reference must also be reproducible from source control, use managed identity by default, keep data-plane services on private paths where practical, and demonstrate regional resilience without pretending every stateful dependency is automatically active-active.
Requirements decide where complexity belongs.
One platform, intentionally separate failure domains.
+ WAF
App Service
+ Service Bus
The architecture is tied to non-functional requirements, not a service checklist.
Front Door and a secondary App Service origin are the production-reference response to regional API failure. Runtime failover behavior still needs to be exercised after deployment.
Inventory reservation and a single authoritative Cosmos write region keep stock ownership explicit instead of treating active-active writes as a free performance feature.
The current single Service Bus namespace is called out as a real regional dependency. The design does not claim an async-processing RTO until continuity is deliberately implemented and tested.
Front Door/WAF is the intended ingress, data services move to private paths in the production profile, and managed identities replace reusable application secrets.
Application Insights and Log Analytics are part of the platform because retries, dead letters, dependency failures, and regional recovery need operational evidence.
Development stays lower-cost, production adds resilience only where requirements justify it, and App Service avoids Kubernetes operational overhead until Kubernetes-specific needs appear.
The architecture makes ownership explicit.
Owns product, cart, checkout acceptance, and order retrieval. It stays focused on the customer-facing request path rather than performing every downstream side effect inline.
Owns reservation, release, and commit transitions. Reservation is the deliberate consistency boundary used to prevent ambiguous stock ownership.
Owns payment-provider interaction and requires idempotent behavior so retries do not duplicate external side effects.
Handles fulfillment transitions independently from the checkout request so shipping failures do not force the customer-facing API to remain open.
Copies business events into Data Lake. Analytics can lag or recover independently because it is intentionally outside the checkout critical path.
Cosmos DB holds operational state, Service Bus carries asynchronous work, Key Vault protects secrets/keys, and Application Insights + Log Analytics provide the operational evidence needed to diagnose failures.
Multi-region compute does not magically make every dependency multi-region.
The production reference places API/worker compute in two regions behind Front Door. Cosmos DB is modeled across both regions with one authoritative write region and automatic failover. Front Door can route around an unhealthy API origin and Cosmos can promote the configured secondary region.
Service Bus continuity is intentionally treated as a separate architecture problem. A regional Service Bus outage can pause asynchronous work in the current baseline, so the project does not claim a messaging RTO that has not been designed and tested.
Different failures take different recovery paths.
unhealthy
health routing
origin
continues
region unavailable
failover
promoted
must be tested
regional outage
dependency
pauses
required
Design for what breaks, not only for the happy path.
Front Door routes to the healthy secondary origin in the production reference profile.
The locked message becomes available for redelivery. Consumers must be idempotent because the crash may happen after an external side effect but before message completion.
Retries stop at the configured limit and the message moves to the dead-letter queue for operational handling rather than retrying forever.
Retry/backoff applies, the order remains incomplete, and reserved inventory must eventually be released instead of becoming permanently stranded.
Cosmos failover promotes the configured secondary region. Observed recovery still needs to be validated under a deployed test.
Asynchronous processing can pause. The current reference records that limitation instead of hiding it behind a generic multi-region label.
What I would prove at runtime.
Make the primary API origin unhealthy and verify Front Door moves traffic. Exercise controlled Cosmos regional failover and record observed recovery instead of assuming the service behavior meets the target.
Crash a worker after a side effect but before completion, prove idempotent redelivery, inject a poison event, and verify dead-letter handling and the associated runbook.
Simulate payment timeouts and verify inventory release, then run a high-contention inventory race to prove the reservation boundary prevents overselling.
Complexity is introduced only where the requirement earns it.
The workload needs independently deployable API and worker processes, not a Kubernetes control plane. App Service keeps the operational surface smaller while preserving scale, managed identity, VNet integration, health checks, and deployment slots.
Payment, shipping, inventory, and analytics can fail or retry independently without forcing the customer request to wait for every downstream dependency.
The design prioritizes a defined inventory-consistency boundary rather than enabling multi-master writes everywhere and creating ambiguous stock ownership.
Private endpoints and DNS keep data-plane services off unnecessary public paths while managed identities remove application secrets from service-to-service authentication.
What has been proven—and what has not.
Requirements, constraints, NFRs, ADRs, diagrams, security, reliability, operations, and known limitations are documented in source control.
Dev, test, and production Bicep and parameter validation is green.
GitHub Actions authenticates with OIDC and the dev architecture completes live subscription-scope ARM What-If evaluation.
Not claimed yet. Application binaries, real failover, performance, recovery, and end-to-end business behavior still require deployment and testing.