Design a Chat System: Architecture and Data Model
A structured framework for the architecture and data model behind a chat system interview question, covering connection gateways, message brokers, Cassandra vs MySQL, and fan-out strategies.
A structured framework for the architecture and data model behind a chat system interview question, covering connection gateways, message brokers, Cassandra vs MySQL, and fan-out strategies.
A structured framework for answering the chat system design interview question, covering WebSocket connections, message ordering, group chat, read receipts, and offline delivery.
A structured framework for answering the notification system design interview question, covering push/email/SMS channels, priority queues, rate limiting, template engines, and delivery tracking.
Token bucket vs. leaky bucket vs. sliding window log — the algorithm choice is only half the design. This piece is about where the limiter physically sits in your request path, and why that placement decision matters as much as the algorithm itself.
A rate limiter that works on one server and breaks across ten is a common interview trap. This is the implementation-level walkthrough: Redis Lua scripts to close race conditions, what actually happens across regions, and where client-side limiting still earns its keep.
Rate limiter questions look simple and punish candidates who treat them that way. This guide covers the four algorithms interviewers expect you to know — token bucket, sliding window, fixed window counter — and how to build a distributed, Redis-backed version that survives a real follow-up.