What this prompt does
This prompt asks the AI to design a Slack-style real-time chat system sized for [user_count] concurrent users. It covers ten requirements: real-time delivery over [transport_protocol], message persistence with [message_retention], at-least-once delivery, presence, group chat up to [max_group_size], file sharing, push notifications, search via [search_engine], read receipts, and optional end-to-end encryption — plus connection management, fanout, database choice, and scaling.
The structure works because the hard parts of chat aren't the features, they're connection management, message fanout, and presence at scale. Passing [user_count] forces the model to reason about how many concurrent connections a single node can hold and how to shard them. [transport_protocol] decides whether you build on WebSockets with an SSE fallback or another transport, and [max_group_size] directly changes the fanout strategy — broadcasting to 1,000 members is a different problem than to 5. Asking for sequence diagrams keeps the message flows explicit.
When to use it
- You're designing a chat or messaging feature and need a real fanout strategy, not just a feature list
- You're prepping for a system design interview on real-time systems
- You need to reason about connection management for
[user_count]concurrent sockets - You're choosing between delivery guarantees and want at-least-once spelled out
- You need a presence system that holds up under load
- You're sizing message persistence and search with
[message_retention]and[search_engine]
Example output
Expect a structured design covering the transport choice, a connection-management and gateway layer, a fanout strategy tuned to [max_group_size], a database and message-store design, a presence subsystem, and sequence diagrams (described or ASCII) for sending a message, going online/offline, and delivering to offline users via push. It reads like a senior-level design doc with the tradeoffs called out.
Pro tips
- Set
[user_count]honestly — 5,000 concurrent users and 5,000,000 lead to completely different connection-sharding answers - Use
[max_group_size]to stress the fanout section; large groups are where naive designs fall apart - If presence matters, ask the model to detail the heartbeat and timeout logic; it's easy to gloss over
- Pin
[transport_protocol]to what you can actually run; WebSockets need sticky sessions or a pub/sub backplane - Ask for the sequence diagrams explicitly per flow — they expose gaps the prose hides
- Treat the end-to-end encryption step as optional scope; it complicates search and history, so only include it if you truly need it
