Strengths

Function & Non-Functional Requirements

• Effectively identified both functional and non-functional requirements with strong independent thinking;
• Demonstrated foresight and system thinking at scale by asking clarifying questions about scale considerations (#DAU, #Chats);
• Applied CAP theory appropriately when evaluating availability v.s consistency for sending/receiving messages;

API Design

• Used clear, structured event message formats and satisfied all functional requirements (create chat, send/receive/delete message).

High-Level Design & Deep Dive

• Selected appropriate technologies, demonstrating your broad system design knowledge and practical experience with distributed system architecture. For example:
  
  
  • Chose WebSocket for bi-directional communication and explained why it's more efficient compared to HTTP (polling-based);
  • Explained S3 pre-signed URL to support media files and mention the usage of CDN to distribute/cache media files to the servers close to actual users;
  • Mentioned the usage of Kafka to ensure message durability and guarantee ordering;
  • Proposed using inbox table to store offline message and articulated the workflow for delivering messages to offline users;
• Was able to identify the bottlenecks with the initial design and proposed techniques to optimize the system and address the scaling concerns:
  
  
  • Proposed Redis pub/sub for efficient message delivery (reducing the lookups latency and server-to-server message routing);
  • Mentioned to use shards to scale database, and replicas to ensure data durability.

Improvement Suggestions

1. Prioritization & Time Management

• Given the time constraints of interviews, you might find it helpful to focus more depth on the most critical workflows. For instance, in a chat application design, the message delivery path—including delivery guarantees, ordering, and low latency—tends to be the most interesting part to explore. While features like media support (S3 pre-signed URLs, CDN) are certainly valuable, a quick mention with less elaboration allows more time for the core messaging flows. This demonstrates your ability to prioritize what matters most.

2. Architectural Clarity

• When introducing new components (like separating the chat service from the WebSocket server), try articulating the specific responsibility of each component and why the separation is beneficial. Clear justification—"Component X handles Y because Z"—helps the interviewer follow your reasoning and shows thoughtful design decisions.

3. Technical Depth

• (Quantitative Analysis) Including back-of-the-envelope calculations when discussing scalability adds credibility to your design choices and demonstrates practical thinking. These estimates don't need to be perfect—they show you can reason about real-world constraints (i.e: how many websocket connections can one server typically handle? how/when to scale?)

4. Additional Considerations Worth Mentioning (A few areas that could strengthen your design discussion if you get this question in a real system design interview)

• Message archiving strategies - helps with cost optimization and DB query performance. (i.e: DB only stores "recent" messages and archives older messages to cheaper storage for offline lookup or auditing).
• Security - briefly touching on encryption (at rest and in transit) shows awareness of compliance and security considerations

Overall, you demonstrated solid foundational knowledge. These suggestions are meant to help you showcase your thinking even more effectively in future interviews.

‍