@RaulJuncoV: Push-based systems come up in 90% of system design interviews. Here's the exercise you should be able to solve: Design …

Push-based systems come up in 90% of system design interviews. Here's the exercise you should be able to solve: Design a notification system for 100M users. Some have 50 followers. Some have 10M. The instinct is to hold a WebSocket connection open to every active user and push updates as they arrive. Clean mental model. It collapses the moment a celebrity posts. When someone with 10M followers posts, you push to 10M open connections simultaneously. Your message broker saturates. Your WebSocket servers fall over. The system fails at the exact moment it needs to work. That's the fan-out problem. And it kills more interview answers than any other mistake. The production answer: push and pull aren't binary. You pick based on follower count. Users with fewer than 1,000 followers get push fan-out. Each follower gets notified immediately. Users with millions of followers get pull fan-out. Their feed assembles on read. Nobody gets a push. Followers see the post when they open the app. Twitter built exactly this: push-on-write for small accounts, pull-on-read for large ones. But fan-out is only half the problem. Push means stateful connections. Your servers now need to know which connection lives on which machine. You can't route blindly. Most teams reach for Redis pub/sub here; the WebSocket server subscribes, the backend publishes, the message finds the right node. Add a 3-second network drop and you have another layer: what did the client miss? Now you need sequence IDs, a message buffer, and reconnect logic that replays missed events. "Push-based" became push with a pull fallback, a message broker, sticky routing, and a replay buffer. Most engineers stop at the first diagram. The ones who get the offer keep pulling the thread until the system breaks.