1. The Scenario — GlobalMart
| Attribute | Detail |
|---|---|
| Users | 10 M active across US, EU, APAC |
| Product Catalog | 5 M SKUs — read-heavy, <10 ms latency globally |
| Order Processing | Transactional, ACID, ~50 K orders/day |
| Sessions & Carts | Ephemeral, high throughput, sub-ms reads |
| Analytics | Historical orders, product performance, executive dashboards |
| Compliance | GDPR (EU data residency), PCI-DSS (payment isolation) |
| Budget | Optimize cost; invest in critical paths (payments, catalog) |
2. Architecture Decisions
A. Product Catalog → Cosmos DB (NoSQL API)
- Why: Multi-region read replicas deliver <10 ms reads in every region; schema-flexible for varied product attributes.
- Consistency: Session — guarantees read-your-writes for merchandising editors while keeping global latency low.
- Partition key:
categoryId— even distribution across 50+ categories; hot partitions avoided. - Cost lever: Autoscale RU/s; reserved capacity for baseline.
B. Orders → Azure SQL Hyperscale
- Why: Full ACID, relational integrity for orders/line-items/payments.
- HA: Failover group across US-East ↔ US-West; geo-replication read replica in EU for local reporting.
- Tier: vCore (Gen5, 8 vCores) — predictable compute for transaction bursts.
- Scaling: Hyperscale allows up to 100 TB; read scale-out for analytics queries.
C. Sessions & Carts → Azure Cache for Redis (Premium)
- Why: Sub-millisecond reads, built-in TTL for ephemeral data.
- Geo-replication: Active geo-replication across two regions for session continuity during failover.
- Eviction:
volatile-lru— expire carts after 24 h inactivity.
D. Analytics → Azure Synapse + Power BI
- Pattern: Change Data Capture (CDC) from SQL → Synapse dedicated pool for historical analysis.
- Power BI: DirectQuery to Synapse for executive dashboards; Import mode for self-service.
- Alternative: SQL read replicas for lightweight operational reports.
E. Payment Data → Isolated Azure SQL + CMK
- Isolation: Separate resource group, separate subscription for PCI scope reduction.
- Encryption: Customer-Managed Key (CMK) via Key Vault; TDE + Always Encrypted for card data.
- Network: Private Endpoints only — no public access; NSG restricts to payment microservice subnet.
F. Data Integration → Event Grid + Functions
- Catalog updates: Merchandising service publishes to Event Grid → Azure Function fans out to Cosmos DB replicas and CDN invalidation.
- Order events: SQL triggers CDC → Event Hub → downstream analytics and notification services.
3. Overall Data Architecture
4. Order Processing Data Flow
5. Compliance Deep-Dive
| Requirement | Implementation |
|---|---|
| GDPR — EU data residency | Cosmos DB write region = West Europe; Azure SQL geo-replica in EU; Azure Policy denies non-EU resource creation in EU subscription |
| GDPR — Right to erasure | Soft-delete + scheduled purge pipeline; Cosmos DB TTL for session data |
| PCI-DSS — Scope reduction | Payment DB in isolated subscription; tokenization — only tokens stored in Order DB |
| PCI-DSS — Encryption | TDE + Always Encrypted (CMK in HSM-backed Key Vault); TLS 1.2 in transit |
| PCI-DSS — Network | Private Endpoints; dedicated subnet; NSG allow-list; no public IP |
6. Cost Optimization
- Cosmos DB: Autoscale RU/s (pay for peak only when needed) + 1-year reserved capacity for baseline.
- SQL Hyperscale: Reserved instances (3-year) for order DB; serverless tier for dev/test.
- Redis: Premium P1 with clustering only if >53 GB; otherwise Standard C3 suffices for sessions.
- Synapse: Serverless SQL pool for ad-hoc; dedicated pool paused outside business hours.
- Networking: Front Door caching reduces Cosmos RU consumption by ~40 % for catalog reads.
🎯 Exam Tip
AZ-305 case studies ask you to match workload characteristics (read-heavy vs. transactional, ephemeral vs. durable) to the correct Azure data service. Always justify consistency model, partition key, and compliance controls — these are the differentiators examiners look for.