System DesignEasy
What are Azure Functions and when would you use them?
Azure Functions is Microsoft's serverless compute service. You write a function, Azure runs it when a trigger fires, and you pay only for the time it executes. There is no VM, no Kubernetes, no app pool to manage.
What "serverless" means here
- Scale-to-zero — when nothing triggers it, no instances run; you pay nothing
- Auto-scale — Azure spins up new instances under load, up to ~200 concurrent
- No infrastructure management — no patching OS, no capacity planning
- Event-driven — every function has a "trigger": HTTP, queue message, timer, blob upload, Cosmos changefeed, etc.
Use cases where Azure Functions shines
| Workload | Why Functions wins |
|---|---|
| Webhook receivers | Stripe/Twilio/GitHub call your URL ~50 times/day → ₹0 most of the time |
| Queue consumers | Service Bus / Storage Queue message → scale-out matches load |
| Scheduled jobs | Nightly reports, weekly cleanup → cron-as-a-service |
| File processing | Blob upload → thumbnail / virus-scan / parse |
| Cosmos change feed | React to DB changes without polling |
| Event Grid handlers | Resource lifecycle events |
| IoT data fan-in | Burst of telemetry → process per device |
Use cases where Functions is the WRONG choice
| Workload | Why Functions loses |
|---|---|
| Customer-facing API at 100+ RPS sustained | Cold start kills p99 latency; cost crossover with App Service |
| Long-running jobs (> 10 min) | Hits the execution timeout (60 min on Premium) |
| WebSockets / SignalR / streaming | Stateless model; use App Service + Azure SignalR Service |
| CPU-heavy batch (video transcoding) | Container Apps Jobs or Batch service is better |
Pricing in plain English
- Free tier: 1 million executions + 400K GB-seconds per month
- Beyond: ~₹0.16 per million executions + ~₹0.016 per GB-second
For most webhook + cron workloads, you stay in the free tier indefinitely. The cost only matters when you hit hundreds-of-thousands of executions per day with non-trivial memory.
A typical decision tree
Is the workload event-driven (HTTP webhook, queue, timer, blob)?
├── Yes → Is traffic bursty / sub-30-RPS?
│ ├── Yes → Azure Functions
│ └── No (sustained high load) → Web API on App Service / Container Apps
└── No (long-lived process) → App Service or Container Apps
Common interview follow-up
"Why not just use Azure Functions for everything?"
Answer:
- Cost crossover at sustained traffic (App Service Plan flat rate beats per-execution past ~30 RPS)
- Cold starts on Consumption (1-5 s for .NET) hurt user-facing latency
- 10-min default execution cap rules out many backend jobs
- Limited middleware story compared to ASP.NET Core
- Vendor lock-in via Azure-specific bindings — hard to port to AWS Lambda
The right answer in 2026: Functions for event-driven workloads, Web API on App Service / Container Apps for sustained-traffic APIs.