Feedback Summary from Your Coach

Tony has provided the following feedback on your session:

"Renhao demonstrated clear structure, strong breadth across requirements, and thoughtful trade-off discussions. Timing and communication were well-managed, and he connected architectural choices to reliability and scalability concerns."

Areas of Strength

• Enumerated all functional requirements, including the special case of threads.
  
  
• Listed non-functional requirements with concrete metrics.
  
  
• Balanced CAP theorem trade-offs, prioritizing availability while addressing consistency nuances in group chat and multi-device management.
  
  
• Strong time management: ~8 min for requirements alignment, ~12 min to HLD, ~25 min to deep dive.
  
  
• Clear API overview (e.g., delete message via chat_id_message_id with JWT-based authentication).
  
  
• Effective comparison of communication protocols.
  
  
• Detailed high-level design for send-message flow (WS server vs. chat server, schemas, etc.).
  
  
• Illustrated offline-to-online recovery flow with inbox table setup.
  
  
• Covered delete message behavior for both online and offline scenarios.
  
  
• Discussed scalability with retention in inbox tables.
  
  
• Expanded WebSocket scalability options: pub/sub, dispatch primary-secondary with discovery/health monitoring, linked to prior real-world work.
  
  
• Explored pub/sub lease mechanisms with TTL.
  
  
• Justified DynamoDB choice for availability (high write throughput, minimal joins).
  
  
• Mapped multi-device considerations to user-level granularity.
  
  
• Raised thoughtful delivery framework prompts, including WS client and load balancer considerations.
  
  

Areas for Improvement

• Expand on data durability and message lifecycle (TTL, archival, compaction, cold storage).
  
  
• When comparing WS to long-polling, explicitly mention cost and efficiency benefits, and contexts where long-polling still applies.
  
  
• Consider separating chat and chat_participant schemas for clarity and scaling.
  
  
• Revisit last_seen usage in inbox table—potential redundancy for single-device delivery; clarify value for multi-client sync.
  
  
• Provide more detail on detecting offline users (heartbeats, WS pings, presence service with TTL, push delivery receipts).
  
  

Suggestions

When choosing between architectural options, tie the decision to real incidents and metrics from past experience. Explain the problem, your approach, and the measurable impact—this signals practical judgment and ownership, which is highly persuasive for interviewers from OpenAI.

‍