$ ls interviews/ # 2 write-ups · 7 questions

Discussed my technical journey so far, emphasizing my focus on WebRTC and how Video SDKs essentially work under the hood.

Design a system capable of processing 1000 live CCTV streams simultaneously. Perform live processing to count the number of humans in the frame on a real-time dashboard, while storing historical data if the user requests it. Make it cloud-agnostic.

I proposed using Application Servers with a Network Load Balancer for horizontal scaling. CloudWatch was suggested for detailed monitoring, alongside persistent WebSocket connections for real-time dashboard updates. For the processing layer, I recommended an FFmpeg pipeline combined with an AI model for human recognition, utilizing DynamoDB for reliable storage. *Self-Reflection:* To be honest, I felt my answer could have been much better. The interviewer pushed hard on ensuring the entire architecture was inherently cloud-agnostic, which introduced extra constraints.

Design a real-time AI phone call agent handling 1,000 concurrent active calls.

I extended my previous architecture. I introduced Redis for ultra-fast chat history retrieval, which feeds directly into the AI layer to generate responses seamlessly. The major constraint remained the same: designing it to be completely cloud-agnostic.

Walked the interviewer through my career progression, the challenges I've tackled, and the tech stack I utilize daily.

I highlighted Claude Code + Cursor as my primary drivers. I use Chrome for research, always maintain a `Claude.md` file for deep project context, actively build out AI skills/prompts within the environment, and use Cursor for rapid, highly-targeted small code changes.

My approach included: Language choice, deployment strategies, horizontal scaling capability, expected traffic estimates, Database selection/partitioning, Sync vs. Async inter-service communication, and robust error handling. *Self-Reflection:* The interviewer seemed to be driving toward a different concept—perhaps emphasizing domain-driven design boundaries, saga patterns, or specific fault-tolerance mechanisms that I didn't initially hit on.

Design a ticket booking system for a massively popular event (e.g., Coldplay concert) with millions of active users trying to book at the exact same time. The total booking window spans 3 hours, but actual tickets run out in mere minutes.

I laid out a High-Level Design (HLD) showing the flow: 1. A Frontend Client connecting through an Application Load Balancer (ALB). 2. Traffic routed to horizontally scaled Application Servers. 3. Row-level locks in Redis to temporarily hold/lock tickets out of the pool. 4. Database replicas handling the heavy read traffic. 5. A separate Payment Handling Microservice pushing transactions asynchronously into a Message Queue. 6. Consumer Services reading the queue to finalize ticket markings in the DB and unblock the holds from Redis once finalized.

• How will events and seats exactly be fetched from the DB with the absolute correct status under such high load?
• How will you mitigate the massive read traffic spike specifically targeting the same single event?
• What happens to the DB transaction if someone attempts to lock a seat at the exact microsecond someone else is fetching it?