# A million taps a second. One tiny message. > 25 million people tapping πŸ”₯ at the same moment β€” and not one of those taps is ever delivered to anyone. - **Format:** short video, 14 steps, ~70 seconds - **Topic:** Live emoji reactions for a cricket final, explained slowly β€” the use case step by step, why sending every tap is impossible, and the five Azure services that count them instead. - **Author:** Suthahar Jegatheesan (MSDEVBUILD) - **Category:** Azure Β· Azure - **Published:** 2026-08-12 - **Tags:** azure, systemdesign, azureeventhubs, azurewebpubsub, realtime, scalability, distributedsystems, streamprocessing, microsoftazure, cloudarchitecture, azurecloud, backenddeveloper, az305, msdevbuild - **Canonical URL:** https://blog.msdevbuild.com/shorts/azure-realtime-reactions-fan-out/ --- ## What you'll learn - The live-reactions use case in four steps β€” what the app actually owes every viewer - Why sending every reaction to every viewer is impossible, in one line of maths - The five Azure services that count instead β€” Front Door, Container Apps, Event Hubs, Stream Analytics, Web PubSub ## Understand it one step at a time ### 1. 25 million people, one ball 25 million viewers, one final ball of the match. Watch the reactions land β€” this is a single second of live traffic, not the whole game. ### 2. A million reactions every second The four emoji counters add up to roughly a million taps every second, sustained for the entire final over of the match. ### 3. What the app has to do Before any architecture gets drawn, write the feature down in plain English first. The actual requirement is only four lines long. ### 4. Way 1: save every tap Writing a million rows a second to a database. It falls over immediately β€” and every phone is stuck waiting on a write that never returns. ### 5. Way 2: send every tap to everyone A million taps broadcast individually to 25 million phones is 25 trillion messages a second. No cloud provider on earth runs at that scale. ### 6. The idea that fixes everything Look at your own screen during a match. You never see one individual person’s tap arrive β€” you only ever see a running total. ### 7. Step 1 β€” Azure Front Door The tap lands at the nearest Azure Front Door point of presence in the world, not on a single origin server in one country. ### 8. Step 2 β€” Azure Container Apps The API on Container Apps accepts the tap, buffers it in memory, and returns immediately. Your phone never blocks waiting on a database. ### 9. Step 3 β€” Azure Event Hubs Instead of 20,000 separate network calls, the app batches 20,000 taps into a single Event Hubs message. Same data, a fraction of the overhead. ### 10. Step 4 β€” Azure Stream Analytics A tumbling 2-second window counts how many of each emoji arrived, emits just the counts downstream, and discards every individual tap. ### 11. Step 5 β€” Azure Web PubSub You publish that one small count message exactly once. Web PubSub fans it out over open WebSocket connections to all 25 million phones. ### 12. The whole thing in one picture A tap goes in at the top; two seconds later an aggregated count comes out at the bottom. Five Azure services, each doing exactly one job. ### 13. Old way vs new way Nothing about the 25 million viewers changed between the two designs. Only what you chose to actually send across the network did. ### 14. Five billion emoji, none delivered Disney+ Hotstar handled over 5 billion reactions across one World Cup with exactly this pipeline. Every tap was counted, then discarded. --- ## The takeaway **Count them. Don’t deliver them.** The moment a live feature tries to send every single event to everyone, a big audience stops being growth and becomes the outage.