# You tapped View Product.

> Five Azure services answer before the page paints. Here is the order they run in.

- **Format:** short video, 12 steps, ~50 seconds
- **Topic:** What happens on Azure when a shopper taps View Product — Front Door, App Service, Cache for Redis, Azure SQL and Blob Storage, in the order the request actually visits them.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure
- **Tags:** azure, azurefrontdoor, azurecdn, azurecache, redis, azuresql, blobstorage, systemdesign, microsoftazure, azurecloud, cloudarchitecture, ecommerce, az305, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/azure-view-product-request-flow/

---
## What you'll learn

- Why the edge answers first and your API never hears about a cache hit
- What cache-aside actually does on a Redis miss, including the write-back
- Why product images take a different path and never reach your API

## Understand it one step at a time

### 1. You tap View Product

One tap on a phone. Everything after it happens in Azure, and it has under a second.

### 2. First stop is the edge, not your app

Front Door and CDN sit in front of everything. The request lands on a POP near the phone.

### 3. Cache hit: your app never wakes up

The edge already holds this response. It answers in 18 ms and your API never sees the request.

### 4. Cache miss: keep going

Nothing cached, or the response says not to cache it. Front Door forwards to the origin.

### 5. The API asks Redis before SQL

App Service takes the request and looks in Azure Cache for Redis first. Always first.

### 6. Redis hit: 2 ms, no database

The product JSON is already in memory. Price, stock, done — and SQL is never queried.

### 7. Redis miss: now you pay for the query

Nothing in memory. The API has to go to the one place that actually owns the data.

### 8. Azure SQL is the source of truth

One indexed lookup on ProductId 123. Price $99, stock 24 — correct, and slower than memory.

### 9. Write it back with a TTL

The API puts the row into Redis before it answers. The next viewer never reaches SQL.

### 10. The image never touches your API

Product photos live in Blob Storage and come off the edge. A completely separate path.

### 11. One tap, five services

Edge, API, cache, database, storage. Each one exists to stop the next one being asked.

### 12. One click. One fast experience

The fast path is the normal path. SQL is the exception — and that is the entire design.

---

## The takeaway

**Every layer exists to stop the next one being asked**

Edge before API, cache before database, storage instead of your app. In that order.