How would you design a real-time location tracking system (like ride-hailing apps)?<\/strong><\/li>\n<\/ol>\n\n\n\nObjective:<\/strong> Track live location of drivers and update rider UI.<\/p>\n\n\n\nKey Features:<\/strong><\/p>\n\n\n\n\n- Location updates every 2\u20135 seconds<\/li>\n\n\n\n
- Nearby driver visibility<\/li>\n\n\n\n
- ETA calculation<\/li>\n<\/ul>\n\n\n\n
Challenges:<\/strong><\/p>\n\n\n\n\n- High frequency GPS updates<\/li>\n\n\n\n
- Offline drivers or sudden disconnects<\/li>\n<\/ul>\n\n\n\n
Approach:<\/strong> Use GPS data sent via mobile SDK. Kafka streams location events. Redis stores latest coordinates. A pub-sub system (like Google Pub\/Sub) notifies matching systems. Stale sessions are expired after a timeout.<\/p>\n\n\n\n\n- How would you design a global file storage system like Google Drive?<\/strong><\/li>\n<\/ol>\n\n\n\n
Objective:<\/strong> Store and sync files across users and devices.<\/p>\n\n\n\nKey Features:<\/strong><\/p>\n\n\n\n\n- File uploads\/downloads<\/li>\n\n\n\n
- Version control<\/li>\n\n\n\n
- Sharing and permissions<\/li>\n<\/ul>\n\n\n\n
Challenges:<\/strong><\/p>\n\n\n\n\n- Handling large file sizes<\/li>\n\n\n\n
- Device conflicts<\/li>\n<\/ul>\n\n\n\n
Approach:<\/strong> Split files into chunks. Store in S3 or similar object storage. Maintain metadata (file name, owner, chunk map) in a DB. Use file hashes for deduplication. Sync tokens help detect changes. CDNs speed up access.<\/p>\n\n\n\n\n- Explain how you would build a rate limiter for distributed APIs.<\/strong><\/li>\n<\/ol>\n\n\n\n
Objective:<\/strong> Restrict number of API calls per user\/IP.<\/p>\n\n\n\nKey Features:<\/strong><\/p>\n\n\n\n\n- Per-user or per-API limits<\/li>\n\n\n\n
- Millisecond-level accuracy<\/li>\n\n\n\n
- Distributed consistency<\/li>\n<\/ul>\n\n\n\n
Challenges:<\/strong><\/p>\n\n\n\n\n- Multiple servers need shared state<\/li>\n\n\n\n
- Handling burst traffic<\/li>\n<\/ul>\n\n\n\n
Approach:<\/strong> Use token bucket or sliding window algorithm. Store counters in Redis. Sync across services via Redis Cluster or sharded cache. Return 429 Too Many Requests with retry-after headers.<\/p>\n\n\n\n\n- How would you design a push notification service at large scale?<\/strong><\/li>\n<\/ol>\n\n\n\n
Objective:<\/strong> Deliver notifications to users in near real-time.<\/p>\n\n\n\nKey Features:<\/strong><\/p>\n\n\n\n\n- FCM\/APNs integration<\/li>\n\n\n\n
- Retry and batch support<\/li>\n\n\n\n
- User preferences<\/li>\n<\/ul>\n\n\n\n
Challenges:<\/strong><\/p>\n\n\n\n\n- Token expiry and failures<\/li>\n\n\n\n
- Volume spikes<\/li>\n<\/ul>\n\n\n\n
Approach:<\/strong> Queue messages with Kafka. Workers send using FCM\/APNs. Batch similar messages. Store preferences in a DB. Use exponential backoff on retries. Remove expired tokens periodically.<\/p>\n\n\n\n\n- Describe your design for a live video streaming service (e.g., Netflix).<\/strong><\/li>\n<\/ol>\n\n\n\n
Objective:<\/strong> Stream high-quality video to users with minimal buffering.<\/p>\n\n\n\nKey Features:<\/strong><\/p>\n\n\n\n\n- Adaptive bitrate streaming<\/li>\n\n\n\n
- Global CDN delivery<\/li>\n\n\n\n
- Real-time playback tracking<\/li>\n<\/ul>\n\n\n\n
Challenges:<\/strong><\/p>\n\n\n\n\n- High bandwidth usage<\/li>\n\n\n\n
- Multi-device compatibility<\/li>\n<\/ul>\n\n\n\n
Approach:<\/strong> Ingest servers process live streams. Transcode into HLS\/DASH formats. Store on cloud storage\/CDNs. Players request chunks based on bandwidth. Analytics system logs view stats and buffering issues.<\/p>\n\n\n\n<\/span>Low Level Design Interview Questions<\/span><\/h2>\n\n\n\nThis section covers important LLD interview questions that test your understanding of object-oriented principles, class design, and system components.<\/p>\n\n\n\n
\n- Design classes for a parking lot management system.<\/strong><\/li>\n<\/ol>\n\n\n\n
Objective:<\/strong> Manage entry, parking, and exit of vehicles.<\/p>\n\n\n\nKey Classes:<\/strong><\/p>\n\n\n\n\n- ParkingLot (has multiple Levels)<\/li>\n\n\n\n
- Level (contains multiple ParkingSpots)<\/li>\n\n\n\n
- ParkingSpot (tracks spot ID, vehicle type, and availability)<\/li>\n\n\n\n
- Vehicle (base class with type, plate number)<\/li>\n\n\n\n
- Ticket (stores entry time, assigned spot, fee details)<\/li>\n<\/ul>\n\n\n\n
Relationships:<\/strong><\/p>\n\n\n\n\n- A Vehicle occupies a ParkingSpot.<\/li>\n\n\n\n
- ParkingLot uses TicketService to generate and close tickets.<\/li>\n<\/ul>\n\n\n\n
Design Tip:<\/strong> Use inheritance for Car, Bike, Truck from Vehicle.<\/p>\n\n\n\n\n- How would you design the core objects and relationships for a tic-tac-toe game?<\/strong><\/li>\n<\/ol>\n\n\n\n
Objective:<\/strong> Model gameplay, players, and win conditions.<\/p>\n\n\n\nKey Classes:<\/strong><\/p>\n\n\n\n\n- Game (controls flow, checks game state)<\/li>\n\n\n\n
- Board (contains a 3×3 grid of Cells)<\/li>\n\n\n\n
- Player (has ID, symbol like X or O)<\/li>\n\n\n\n
- Move (stores player and cell coordinates)<\/li>\n<\/ul>\n\n\n\n
Design Tip:<\/strong> Use GameState enum (IN_PROGRESS, DRAW, WIN) to track status.<\/p>\n\n\n\nBonus:<\/strong> Add AIPlayer for single-player mode.<\/p>\n\n\n\n\n- Create object-oriented models for an API rate limiter<\/strong><\/li>\n<\/ol>\n\n\n\n
Objective:<\/strong> Control API request volume per user\/IP.<\/p>\n\n\n\nKey Classes:<\/strong><\/p>\n\n\n\n\n- RateLimiter (entry point for checking limits)<\/li>\n\n\n\n
- UserBucket (stores allowed requests and refill time)<\/li>\n\n\n\n
- Token or Permit (optional object to signal request grant)<\/li>\n<\/ul>\n\n\n\n
Logic:<\/strong><\/p>\n\n\n\n\n- Sliding window or token bucket logic is implemented in UserBucket.<\/li>\n\n\n\n
- RateLimiter maps users to their respective UserBucket.<\/li>\n<\/ul>\n\n\n\n
Design Tip:<\/strong> Keep time-based logic inside each bucket for encapsulation.<\/p>\n\n\n\n<\/span>High Level Design Interview Questions<\/span><\/h2>\n\n\n\nThis section includes key HLD interview questions that focus on system architecture, scalability, and component interaction at a broader level.<\/p>\n\n\n\n
\n- Design the architecture for a URL shortening service.<\/strong><\/li>\n<\/ol>\n\n\n\n
Goal:<\/strong> Accept long URLs and return short, unique aliases.<\/p>\n\n\n\n