Design a Scalable Alert Manager

Read the asymmetry before you draw anything. Alerts arrive in a flood, mostly repeats of a handful of underlying problems. The output should be small: the things a security analyst should spend attention on. A single misconfigured firewall rule or a port scan can raise the same alert tens of thousands of times a minute. If the design forwards each one to a human, you have built a machine for burying real threats under noise. So the core job is reduction. Turn a firehose of raw alerts into a trickle of distinct, grouped incidents. Do it fast enough that a genuine breach still pages someone within seconds.

That framing changes what "scalable" means here. The write side is huge and bursty. The read side is tiny and calm. Between them sits the interesting work: deduplication, grouping, suppression, and reliable delivery. Say that out loud in the first two minutes and every later choice follows from it. Reduction is the job. Bytes are not the hard part.

The Palo Alto Networks angle

Palo Alto Networks interviews like a security company, and this design sits squarely in their world. Their products live and die on the SOC analyst's experience: alerts stream off firewalls and sensors, and the value is in cutting that stream down to the few incidents worth chasing. "Design Twitter" wearing a badge won't land. The interviewer wants someone who sees alert fatigue as the enemy and builds the system around dedup and grouping. The system-design round here runs lighter than a FAANG scale-everything loop and leans practical and infrastructure-flavored. For senior and principal candidates it often shows up as an explicit low-level design round. Be ready to go concrete on the data model and the state machine, beyond boxes and arrows.