Cracking the Meesho Backend Engineer Interview
Backend Engineers at Meesho build the highly scalable distributed systems that handle millions of product searches, inventory updates, and order processing workflows daily. The interview process is brutally focused on high-level system architecture, database optimization, and writing concurrent, scalable code capable of supporting massive e-commerce traffic.
Phase 1: Advanced Data Structures & Algorithms
Before designing systems, you must prove you can write optimal code.
- The Focus: Expect Medium to Hard LeetCode problems. Focus heavily on Graphs, Dynamic Programming, and advanced Tree traversal.
- Concurrency: You may be asked to write thread-safe code. "Implement a rate limiter" or "Design a concurrent task scheduler." You must understand locks, semaphores, and race conditions.
Phase 2: Database Design and Low-Level Design (LLD)
Meesho relies heavily on efficient data storage and complex logistics routing.
- Database Internals: You must understand how databases work under the hood. "Explain how a B-Tree index works in MySQL." "What is the difference between optimistic and pessimistic locking?" (Crucial for inventory management).
- SQL vs. NoSQL: "When would you use Redis, MongoDB, or MySQL for different parts of an e-commerce platform?"
- Low-Level Design (Machine Coding): You will be asked to design the class architecture and database schema for a feature (e.g., "Design an Order Management System"). Focus on SOLID principles and design patterns.
Phase 3: High-Level System Design (The Decider)
This round defines your level (SDE II vs. SDE III).
- The Scenario: "Design Meesho's checkout and inventory reservation system to handle a major festive sale."
- Key Components to Discuss:
- High Throughput: How do you handle millions of users adding items to a cart simultaneously? (Hint: Kafka, in-memory grids).
- Consistency: How do you ensure you don't oversell an item during a flash sale? (Hint: Distributed locks, Redis Lua scripts, Database transactions).
- Scalability: How do you scale the database to handle the surge in orders? (Hint: Database Sharding, Read Replicas).
Top 3 Technical Questions to Prepare
- Design a distributed Rate Limiter that allows a maximum of 100 API requests per minute per user across a cluster of servers.
- Explain how Kafka works. How do you ensure exactly-once processing of order messages in a distributed messaging queue?
- Two users click "Buy" on the last kurti in stock at the exact same millisecond. Walk me through the architecture required to ensure only one user successfully purchases it, while the other receives an "Out of Stock" message.



