The 5-Minute System Design Question Most Engineers Get Wrong

#discuss #interview #webdev #career

There's a system design question that keeps showing up in interviews at Google, Amazon, Meta, and pretty much every tech company:

"Design a basic chat message system that allows users to send and receive messages in real-time. You have 5 minutes."

Sounds straightforward. But data from tech hiring shows around 73% of engineers struggle with it—not because it's technically hard, but because they approach it the wrong way.

The Two Mistakes Everyone Makes

Jumping Straight Into Implementation

Most candidates hear "chat system" and immediately start talking about WebSockets, Redis, or database schemas.

The problem? They haven't asked basic questions first:

Is this for 100 users or 100,000?
One-on-one chat or group rooms?
Do messages need to persist, or can they disappear?

A chat system for 100 concurrent users is a weekend project. For 100,000 users, you need horizontal scaling, message queues, and load balancers. Without knowing the scale, you're designing blind.

Focusing on One Component

Engineers often spend the entire 5 minutes on database design while completely ignoring:

Components that actually matter in a chat system:
├── WebSocket connections (real-time delivery)
├── Message storage (what happens when users are offline?)
├── User presence tracking (who's online?)
├── Delivery confirmation (did the message arrive?)
└── Connection management (handling disconnects)

Chat systems are fundamentally about real-time communication and connection management - not just storing data.

The Framework That Works

Here's a breakdown that consistently helps candidates pass:

Minute 1 - Clarify Requirements
Ask about scale, features, and constraints before touching anything.

Minutes 2-3 - Draw High-Level Components

┌─────────────┐     ┌─────────────┐     ┌─────────────────┐
│ Client Apps │────▶│ Chat Server │────▶│ Message Database│
└─────────────┘     └─────────────┘     └─────────────────┘
                           │
                    ┌──────┴──────┐
                    ▼             ▼
            ┌───────────┐  ┌─────────────┐
            │Connection │  │  Message    │
            │ Manager   │  │   Queue     │
            └───────────┘  └─────────────┘

Briefly explain each: client apps, chat server for routing, database for history, connection manager for presence, message queue for reliability.

Minutes 4-5 - Address the Hard Parts

Message ordering with multiple servers
Handling reconnection and missed messages
Scaling WebSocket connections across servers

What Interviewers Actually Want

Testing For	NOT Testing For
Thinking through distributed systems	Memorizing specific technologies
Asking clarifying questions	Having one "correct" answer
Communicating trade-offs	Writing perfect code
Staying organized under pressure	Speed

The point isn't to design WhatsApp in 5 minutes. It's to show you can break down an open-ended problem systematically.

Quick Reference

const systemDesignFramework = {
  minute_1: "Clarify - scale, features, constraints",
  minute_2: "Draw - clients, servers, storage",
  minute_3: "Trace - how data flows through",
  minute_4: "Identify - scaling challenges, failure points",
  minute_5: "Trade-offs - what you'd prioritize and why"
};