What Happens When Your App Runs on Azure
A Clear Behind-the-Scenes Look at How a Real Web Request Moves Through Azure
What happens behind the scenes of a solution running on Azure?
We can see this by taking a look at how components interact in a typical web request. So feel free to comment on this architecture.
Let’s take a simple basic web app:
A user visits a public site. The site runs on Azure App Service.
Traffic enters through Azure Front Door.
The app calls an API inside a virtual network.
The API writes data to an Azure SQL database.
Everything runs in one Azure region with zone level redundancy.
High level, it looks like this:
User → Public Internet → Azure Global Network → Regional Layer → VNet
Start with the user click
A click generates a packet. The packet travels across the public internet. Routers move it based on standard routing protocols. Azure is not involved yet.
Entry to Azure
The packet reaches the closest Azure edge location. Front Door performs global routing to the correct region.
Azure global network movement
Traffic moves entirely across private switches and routers controlled by the platform. This is the long-haul network that moves your traffic from the nearest Azure edge location to the region that hosts your app.
Region Arrival
A cluster of datacenters in one geographical location. If Application Gateway is present, it performs layer seven routing. It reads headers, paths and cookies. It examines headers and paths, then forwards the request to the App Service front end.
App Service
Your code runs inside a sandbox. The compute host assigns CPU, memory and network interfaces. Physical servers under the host run on Azure designed hardware. An internal load balancer picks a healthy worker for each request. Your app receives the request. It parses data, applies logic and prepares to call downstream services.
Move into the virtual network
When App Service calls the API, the packet moves into the VNet through the configured VNet Integration.
Inside the VNet:
Virtual switches control routing
Subnets isolate resources
NSGs apply rules only to resources inside those subnets
User-defined routes influence how traffic flows
The packet reaches the API.
API execution (Represented by an Azure function - premium plan here)
The API runs on its own compute hosts. It processes the request then sends a query to Azure SQL.
The API processes the request and sends a query to Azure SQL.
Storage and hardware
Azure SQL stores data on clusters of physical disks backed by distributed replicas. Writes land in durable storage protected by multiple failure domains.
Return path
The response flows back along the same connection:
SQL returns data to the API
API returns data to App Service
App Service generates the final response
The connection returns through App Gateway if present
Front Door sends it back across Azure’s backbone
The closest edge site returns it to the public internet
The browser renders the result.
That’s all for today, see you in the next one.