Real-world Scenarios
Four complete end-to-end scenarios putting all Azure Core Services together — the kind of architecture decisions you'll make and defend on the job and in interviews.
Scenario 1: Host a Web Application
Brief: A startup needs to deploy a Node.js API and React frontend. Expected 5,000 daily active users, growing to 50,000 in 6 months. Team of 3 engineers.
Architecture Decision
| Component | Azure Service | Why |
|---|---|---|
| React frontend | Blob Storage (Static Website) + Azure CDN | Near-zero cost, global CDN distribution |
| Node.js API | App Service (Standard S2) | PaaS simplicity, deployment slots, auto-scale |
| Database | Azure SQL Database (S2) | Managed relational, automatic backups |
| File uploads | Blob Storage (Hot tier) | Scalable object store, SAS tokens for uploads |
| Background tasks | Azure Functions (Consumption) | Email notifications, image processing, free tier |
Walk-through
- Enable static website on a Blob Storage account. Upload React build to
$webcontainer. - Create Azure CDN profile pointing to the blob endpoint for global edge caching.
- Create App Service Plan (Standard S2) and deploy Node.js API via GitHub Actions.
- Create Azure SQL Database (S2 DTU). Store connection string as App Setting (Key Vault reference).
- Add a staging slot on App Service. Configure CI/CD to deploy to staging, then swap to prod.
- Create Azure Functions app with blob trigger for image resizing and HTTP trigger for queued emails.
App Service S2 (~$70/mo) + Azure SQL S2 (~$30/mo) + Blob Storage + Functions. Total: roughly $120-150/month for a production-grade setup. Scales affordably as traffic grows.
Scenario 2: Lift-and-shift Legacy Backend
Brief: A 10-year-old Windows app uses a COM component and SQL Server with SQL Agent jobs, linked servers, and a UNC file share. Move to Azure with minimum code changes.
Architecture Decision
| Component | Azure Service | Why |
|---|---|---|
| App server | Azure VM (Windows Server 2019) | COM components require full OS control |
| Database | SQL Managed Instance | SQL Agent, linked servers, near-100% SQL Server compat |
| File share | Azure Files (SMB) | Replace UNC share; VMs mount it the same way |
| Availability | Availability Set + Load Balancer | Redundancy without refactoring to stateless |
Walk-through
- Create a VNet with separate subnets for App servers and SQL MI (SQL MI requires a dedicated subnet).
- Deploy SQL MI to its subnet. Run Database Migration Service to migrate from on-prem SQL Server.
- Deploy Windows VMs into an Availability Set. Install app, configure COM components.
- Create Azure Files share and mount it on all VMs at the same UNC path the app uses.
- Update connection strings to point to SQL MI endpoint.
Scenario 3: Media Platform File Uploads
Brief: Users upload videos (up to 2 GB). Videos need transcoding. Processed videos are served to global users. Storage must be cost-effective — old videos are accessed rarely.
Architecture Decision
| Component | Azure Service | Why |
|---|---|---|
| Upload | Blob Storage (direct SAS upload) | Bypass API server — large files go direct to blob |
| Transcoding trigger | Azure Function (Blob trigger) | Fires on new upload, adds to processing queue |
| Transcoding workers | ACI (batch containers) | Per-job containers, only pay during transcoding |
| Processed video storage | Blob (Cool→Archive lifecycle) | Hot for first 30 days, Cool after, Archive if old |
| Delivery | Azure CDN | Edge delivery of finished videos globally |
| Metadata | Azure SQL Database | Video titles, user IDs, status — relational |
Walk-through
- Frontend requests a SAS write token from API for direct-to-blob upload (never proxies video through API).
- Function fires on blob creation → writes transcoding job to Queue Storage → ACI container picks up job.
- ACI container transcodes, writes output to
processedblob container, marks job complete in SQL DB. - CDN origin points to the
processedblob container. - Lifecycle policy: Hot → Cool (30 days) → Archive (365 days).
Scenario 4: Choosing the Right Database
Different data types need different databases. Here's how to match them:
| Data Type | Service | Reason |
|---|---|---|
| User accounts, orders (relational) | Azure SQL or Postgres | Transactions, joins, ACID guarantees |
| Product catalog (semi-structured JSON) | Cosmos DB (NoSQL API) | Schema flexibility, fast global reads |
| Session data (ephemeral key-value) | Azure Cache for Redis | Sub-millisecond in-memory access |
| Log data / telemetry | Table Storage or Azure Data Explorer | Cheap write-heavy time-series storage |
| User files / media | Blob Storage | Unlimited object storage, lifecycle policies |
| Shared app config files | Azure Files | Mount as file share across all app instances |
Key Architecture Principles
- Right service, not cheapest or most complex: ACI for batch, AKS for microservices, App Service for web — don't force everything into one compute.
- Store secrets in Key Vault: Connection strings, API keys — never in app settings as plaintext if avoidable.
- Private endpoints for production: Keep storage and databases off the public internet; use VNet private endpoints.
- Redundancy by design: Zone-redundant storage, availability zones for VMs, geo-replication for databases.
Summary
Real architectures combine multiple Azure services. The skill is in knowing which service to pick for each job — and being able to justify the decision in terms of cost, complexity, and operational overhead. Practice drawing architecture diagrams for each scenario type.