ECommerce Enterprise Architecture Blueprint

⏱ 17 min read

This guide presents a complete enterprise architecture blueprint for a modern eCommerce platform, modeled in Sparx Enterprise Architect using the ArchiMate modeling language. It covers every layer of the architecture — from executive strategy and governance down to microservices, databases, and cloud infrastructure — with 55 real diagrams exported from Sparx EA.

Whether you are an enterprise architect planning a digital commerce platform, a solution architect evaluating microservices patterns, or a TOGAF practitioner looking for a concrete ADM example, this reference demonstrates how Sparx EA can serve as the single source of truth for architecture documentation across all layers. ArchiMate in TOGAF ADM

What This Architecture Covers

The ECommerce Architecture Blueprint spans eight chapters, each corresponding to a major architecture domain:

• Governance & Decisions — Architecture principles, decision records (ADRs), standards, and compliance
• Strategy & Motivation — Business drivers, strategic goals, scope and phase planning
• Requirements — 30 functional requirements, 15 non-functional requirements, and constraints
• Business Architecture — Capability maps, business processes, roles, and RACI matrices
• Application Architecture — 25 microservices, service landscape, technology stack, and data model
• Technology Architecture — Infrastructure nodes, network topology, and cloud deployment
• Traceability Patterns — Complete value chain from drivers to running infrastructure
• View Library — Curated views for executives, architects, and operations teams

Chapter I: Governance & Decisions

The architecture's rules of the road: the ten principles every design decision must honour, the fifteen ADRs that capture major choices, the standards framework, and the governance organisation.

1.1 Architecture Principles

Ten architecture principles define the non-negotiable qualities this platform must exhibit. They are not aspirational — they are binding constraints that any design decision must satisfy. The diagram below shows how these principles depend on and reinforce each other.

Architecture Principles Framework

Automate Toil Away

All repetitive operational work must be automated. Manual steps in build, deploy, test, and monitoring pipelines are technical debt to be eliminated.

Observability Required

Every service must emit structured logs, metrics, and distributed traces. Observability is a first-class deliverable, not a post-launch addition.

Cloud-Native by Default

Workloads run on Kubernetes (AKS). Infrastructure is managed as code with Terraform. Stateless services and managed data stores are preferred.

Fail Fast, Recover Faster

Circuit breakers, retries with back-off, and automated rollback ensure failures are detected quickly and their blast radius minimised.

Security by Design

Zero-trust networking (Istio), secrets in Azure Key Vault, and threat modelling integrated into the SDLC. Security is never bolted on.

Event-Driven Architecture

Services communicate asynchronously via Apache Kafka wherever possible. Tight synchronous coupling is a red flag in design reviews.

API-First Architecture

All capabilities are exposed through versioned, documented APIs before UI is built. The API contract is the product.

Data as Strategic Asset

Data quality, lineage, and governance are owned by named teams. No service owns data it does not produce.

Cost-Conscious Architecture

Every infrastructure decision includes a cost model. Auto-scaling policies are tuned to match actual load patterns.

Buy Before Build

Commodity capabilities (payments, email, maps) are sourced from mature SaaS products unless a compelling competitive differentiator exists.

1.2 Architecture Decision Records

Architecture Decision Records (ADRs) document the major technical choices made during the project, the context in which they were made, and the trade-offs accepted. The fifteen ADRs below form a dependency chain: the foundational decision to adopt a Microservices Architecture (ADR-001) cascades into decisions about event streaming, deployment, security, and delivery.

ADR-02 Decision Timeline & Dependency Chain

• ADR-001

  Microservices Architecture

  The foundational decision. The platform is decomposed into independently deployable services, each owning its domain and data store. Enables independent scaling and team autonomy.

• ADR-002 — Kubernetes on Azure (AKS)
  Managed Kubernetes chosen as the orchestration layer. Azure Kubernetes Service provides the control plane, reducing operational overhead while retaining full container scheduling flexibility.
• ADR-003 — Apache Kafka for Events
  Kafka is the event bus for all asynchronous inter-service communication. Supports replay, fan-out, and time-decoupled consumption patterns critical for order and inventory flows.
• ADR-004 — Database-Per-Service Pattern
  Each microservice owns its own PostgreSQL schema or MongoDB collection. Shared databases are prohibited. Maintains loose coupling and allows independent schema evolution.
• ADR-005 — Kong
  
  

  API Gateway

  Kong provides the single ingress point for all external API traffic. Authentication, rate limiting, request transformation, and routing policies are centralised here.

• ADR-006 — React + Next.js PWA
  The storefront is a Progressive Web App built with Next.js (server-side rendering for SEO) and React. Targets near-native mobile performance with a single codebase.
• ADR-007 — Multi-PSP (Stripe + Adyen)
  Two payment service providers provide redundancy and international coverage. Failover logic routes payments automatically when one PSP is degraded.
• ADR-008 — Observability Platform
  Prometheus + Grafana for metrics, Jaeger for distributed tracing, and Azure Log Analytics for log aggregation. Every service emits all three telemetry types.
• ADR-009 — GitOps with ArgoCD
  Deployment state is declared in Git. ArgoCD reconciles the cluster state to match. No direct kubectl apply in production — all changes go through pull request.
• ADR-010 — Trunk-Based Development
  All engineers commit to a single main branch with short-lived feature branches (≤2 days). Enables the 5× daily deployment cadence targeted in strategy.
• ADR-011 — LaunchDarkly
  
  

  Feature Flags

  Feature flags decouple deployment from release. Dark launches, canary rollouts, and A/B tests are managed without code deploys.

• ADR-012 — Zero Trust Security
  Istio service mesh enforces mTLS between all services. No implicit trust based on network position. Identity-based access control applies inside the cluster.
• ADR-013 — Elasticsearch Search
  Product search and discovery are powered by Elasticsearch, supporting full-text search, faceted filtering, and relevance tuning independent of the product database.
• ADR-014 — Terraform IaC
  All Azure resources are defined in Terraform modules. Infrastructure changes go through CI/CD with plan review before apply. Drift detection is automated.
• ADR-015

  Testing Strategy

  70% unit tests, 20% integration tests, 10% end-to-end tests. Contract tests (Pact) cover service boundaries. Performance tests run nightly in a staging environment.

Chapter II: Strategy & Motivation

Eight business forces drive ten strategic goals. This chapter traces the motivation from external pressures down to specific, measurable outcomes the architecture must deliver.

2.1 Executive Strategy Map

The strategy map below is the single most important view for executive stakeholders. It shows how business drivers cascade into strategic goals and how infrastructure choices support them. Every node is a commitment with a measurable target.

VIEW-01 Strategy Map (Executive) +6% Market Share Target −25% Infrastructure Cost ($675K) +40% Conversion Rate (to 2.5%) NPS 40 Industry-Leading Score 99.9% Platform Uptime −60% Fraud Reduction (to 0.8%) 5×/day Deployment Frequency $50K/hr Downtime Cost (avoided) Key insight: Amazon competition (38% share) and mobile growth (72% of sessions) are the primary external pressures. The architecture must deliver mobile parity and a marketplace feature to compete, while simultaneously reducing infrastructure waste to fund the investment.

2.2 Business Drivers

Eight business forces shape every architectural decision. These are not abstract aspirations — they are the real conditions the business operates in and must respond to.

Business Drivers & Relationships

2.3 Scope & Phase Timeline

The initiative is phased to deliver value incrementally. The scope diagram separates what is being built, bought, or deferred. The phase timeline maps deliverables to quarters.

SCOPE-01 Scope Overview

Chapter III: Requirements

Thirty functional requirements, fifteen non-functional requirements, and eight hard constraints define what the system must do, how well it must do it, and what it must never violate.

3.1 Functional Requirements Hierarchy

The requirements are not isolated statements — they form a dependency graph. The diagram shows how checkout-related requirements cascade into inventory, payment, and notification requirements.

Requirements Hierarchy (30 Functional)

Key requirements from the model include:

ID	Requirement	Category
REQ-001	Guest Checkout — purchase without registration	Checkout
REQ-002	One-Click Checkout for returning customers	Checkout
REQ-003	Real-Time Cart Total with dynamic pricing	Checkout
REQ-004	Multiple Payment Methods (card, wallet, BNPL)	Payment
REQ-007	Order Confirmation Email within 30 seconds	Orders
REQ-008	Real-Time Order Tracking with carrier integration	Orders
REQ-011	Real-Time Stock Check during browse and checkout	Inventory
REQ-012	Stock Reservation During Checkout (10-minute hold)	Inventory
REQ-013	Low Stock Indicators on product pages	Inventory
REQ-014	Alternative Product Suggestions when out-of-stock	Discovery
REQ-023	Address Book with multiple saved addresses	Profile
REQ-024	Payment Methods Vault (PCI-DSS compliant)	Payment
REQ-026	Easy Returns — self-service return initiation	Returns

3.2 Non-Functional Requirements

The NFR framework establishes quality thresholds across performance, security, reliability, and maintainability. These are enforced in CI/CD gates — a service that violates them cannot be promoted to production.

NFR Framework with Dependencies

Critical NFRs include: p99 API latency <200ms, checkout page load <3s on 3G, 99.9% monthly uptime SLA, PCI-DSS Level 1 compliance, WCAG 2.1 AA accessibility, and MTTR <15 minutes for Sev-1 incidents.

Chapter IV: Business Architecture

Fifteen business capabilities, eight core processes, and twelve business roles define what the organisation does — independent of the technology that supports it.

4.1 Capability Map

The L1 Capability Map defines what the business does at the highest level. Capabilities are business outcomes, not IT systems. Order Management sits at the heart, triggering Fulfillment and requiring both Inventory Management and Payment Processing to function.

L1 Capability Map with Dependencies

Core Transactional Capabilities

• Order Management (central hub)
• Payment Processing
• Inventory Management
• Fulfillment & Delivery
• Returns Management
• Fraud Detection & Prevention

Growth & Insight Capabilities

• Product Catalog
• Search & Discovery
• Marketing & Promotions
• Pricing Management
• Analytics & Insights
• Customer Management
• Identity & Access Management
• Loyalty (via Returns)
• Customer Service

4.2 Core Business Processes

Core Business Process Flows

4.3 Roles & RACI

RACI Matrix — Roles to Capabilities

Chapter V: Application Architecture

Twenty-five microservices, a GraphQL gateway, a PWA storefront, and a native mobile app form the application layer. This chapter documents the landscape, the integration topology, and the component-level technology choices.

5.1 Microservices Landscape

The platform is decomposed into 25 independently deployable microservices, each aligned to a bounded domain context. The Web Storefront (PWA) routes through the API Gateway, which fans out to domain services. The GraphQL Gateway provides a unified query surface for complex data fetching.

Microservices Landscape & Integration Map

Service	Domain	Role
Web Storefront (PWA)	Frontend	Next.js progressive web app — primary customer interface
Mobile App (Native)	Frontend	iOS/Android native application
API Gateway	Platform	Kong — single ingress, auth, rate limiting, routing
GraphQL Gateway	Platform	Federated schema across catalogue, cart, orders
User Service	Identity	Authentication, profile, address book
Catalog Service	Commerce	Product data, attributes, categories
Search Service	Commerce	Elasticsearch-backed full-text + faceted search
Recommendation Engine	Commerce	Python ML service for personalised suggestions
Cart Service	Commerce	Session-scoped cart with Redis persistence
Pricing Service	Commerce	Dynamic pricing, promotions engine integration
Checkout Service	Commerce	Orchestrates cart → payment → order creation
Payment Service	Finance	Stripe + Adyen integration, PCI-DSS scope boundary
Tax Service	Finance	Jurisdiction-aware tax calculation
Order Service	Fulfilment	Order lifecycle management, event source
Inventory Service	Fulfilment	Stock levels, reservations, low-stock alerts
Fulfillment Service	Fulfilment	Warehouse + carrier integration
Shipping Service	Fulfilment	Carrier rate shopping, label generation
Returns Service	Fulfilment	RMA processing, refund initiation
Notification Service	Engagement	Email, SMS, push — triggered by order events
Promotion Service	Engagement	Discount codes, campaign rules
Loyalty Service	Engagement	Points accrual and redemption
Review Service	Engagement	Product ratings and reviews
Fraud Detection Service	Risk	Real-time transaction scoring, rule engine
Analytics Service	Intelligence	Behavioural events, funnel analysis, reporting
Admin Portal	Internal	Back-office for operations, catalogue management

5.2 Service Landscape & Domain Boundaries

SVC-01 Service Landscape Core stack at a glance: Next.js PWA · Node.js microservices · Python ML · Apache Kafka · PostgreSQL · MongoDB · Redis · Elasticsearch · Kubernetes (AKS) · Istio · Kong · Prometheus/Grafana · Jaeger · ArgoCD · GitHub Actions · Terraform

5.4 Logical Data Model

Logical Data Model (ERD)

Chapter VI: Technology Architecture

Twenty infrastructure nodes on Microsoft Azure form the deployment substrate. This chapter documents the network topology, the security boundaries, and the observability stack.

6.1 Infrastructure Architecture & Network Topology

Infrastructure Architecture & Network Topology

Node	Service	Purpose
CDN + Front Door	Azure	Global edge, TLS termination, WAF, geo-routing
Application Gateway	Azure	L7 load balancing, SSL offload, health probes
API Gateway	Kong	API management, plugins, consumer authentication
AKS Cluster	Azure Kubernetes	Container orchestration for all microservices
Load Balancer	Azure	Internal L4 load balancing for AKS node pools
PostgreSQL Cluster	Azure Database	Relational data for transactional services
Redis Cache Cluster	Azure Cache	Session data, cart state, rate limiting counters
Kafka Event Bus	Azure Event Hubs	Async event streaming between services
ElasticSearch Cluster	Azure	Product search and log aggregation
Azure Blob Storage	Azure	Product images, static assets, backups
Azure Key Vault + HSM	Azure	Secrets management, certificate storage
Container Registry	Azure ACR	Private Docker image registry
DevOps Agents	Azure DevOps	CI/CD pipeline execution agents
Prometheus + Grafana	Self-managed	Metrics collection and dashboards
Jaeger Tracing	Self-managed	Distributed request tracing
Azure Monitor	Azure	Platform metrics, alerts, Log Analytics workspace
Azure Backup	Azure	Database and blob backup with geo-redundancy
Azure DNS	Azure	Public DNS management
Azure Private Link	Azure	Private connectivity to PaaS services
Azure Bastion	Azure	Secure RDP/SSH access to VMs without public IPs

Chapter VII: Traceability Patterns

The complete value chain connects every business driver to the infrastructure node that ultimately delivers it. Six traceability diagrams form a continuous thread from strategy to silicon.

7.1 Complete Value Chain

The value chain is the most powerful governance tool in the architecture. It proves that every infrastructure investment is traceable to a strategic goal, and that every strategic goal has at least one concrete technical delivery.

TRACE-01 Complete Value Chain

7.2–7.6 Traceability Chain

TRACE-03 Goals → Requirements

Chapter VIII: View Library

Curated views for three audiences: executives who need strategic clarity, architects who need design detail, and operations teams who need runtime topology.

8.1 Executive Dashboard

VIEW-02 Investment Portfolio (Exec)

ARCH-04 Requirements → Capabilities

VIEW-07 Technology Stack (Arch) End of Document

Closing Remarks

This architecture represents a modern, cloud-native, event-driven ECommerce platform designed to compete at scale. Its ten architecture principles, fifteen ADRs, and complete traceability chain from business driver to infrastructure node form a cohesive and auditable design that can guide teams through multi-year delivery. enterprise cloud architecture patterns

The model was captured in Sparx Enterprise Architect and follows ArchiMate 3.1 notation throughout. All diagrams and content contained in this document are derived directly from that model. enterprise architecture guide

Next steps: Use the ADR list as a starting checklist for architecture review board sign-off. Use the traceability diagrams (Chapter VII) to validate that proposed changes to any layer ripple correctly through the chain. Use the Executive Dashboard views (Chapter VIII) for programme governance reporting.