System Design Interview Patterns for Indian Product Companies 2026: HLD, LLD, Scalability & Top Questions

Most user-facing systems are 80–90% reads. The pattern: put a cache layer in front of the database. Cache-aside (lazy loading) is the most common strategy — check cache first, miss → fetch from DB → populate cache.

• L1 Cache: In-process memory cache (Guava Cache, Caffeine) — sub-millisecond, but per-instance, inconsistent
• L2 Cache: Redis cluster — shared across instances, millisecond latency, supports rich data types
• L3 Cache: CDN (CloudFront, Akamai) — for static assets and API responses that change rarely
• Cache Invalidation Strategies: TTL (simple, stale risk) | Write-through (consistent, extra write) | Write-behind (async, faster writes, data loss risk)
• Cache Stampede Problem: Thundering herd on cache miss → use probabilistic early expiration or request coalescing

When writes burst (order placement, payment events, user actions) you can't synchronously write to all downstream systems. Decouple with a message queue: write fast to the queue, process asynchronously.

• Kafka (preferred for high-throughput, durable, replay): Order events, payment events, analytics pipelines. Retention enables replay for debugging and backfill.
• RabbitMQ (preferred for task queues, routing complexity): Email/SMS sending, background jobs, flexible message routing with exchanges.
• Fan-out Pattern: One event → multiple consumers. Example: "order placed" → [inventory service, notification service, analytics service, warehouse service] all consume independently.
• Backpressure: If consumers are slow, queue grows. Solutions: auto-scaling consumers, circuit breaker on producer side, dead-letter queue for failed messages.

When a single database can't handle the load (typically >10M rows or >10K QPS), horizontally partition data across multiple shards. Each shard holds a subset of the data.

• Range-based sharding: Users A–M on shard 1, N–Z on shard 2. Simple but creates hotspots (most users might be A–M).
• Hash-based sharding: shard = hash(userId) % N. Uniform distribution but rebalancing when adding shards is expensive.
• Consistent hashing: Virtual ring — adding/removing a shard only affects neighboring shards. Preferred for dynamic scaling.
• Shard Key Selection: Choose a key with high cardinality and even distribution. Bad shard key = hot shard. E.g., sharding tweets by userId distributes load evenly; sharding by creation date creates temporal hot shards.
• Cross-shard queries: JOINs across shards are expensive. Denormalize or maintain a global index for cross-shard lookups.

Rate limiting controls how many requests a client can make in a time window. Essential for API protection, fair usage, DDoS mitigation.

• Token Bucket: Each user gets N tokens/second. Each request consumes 1 token. Tokens accumulate up to a max bucket size. Allows burst traffic within burst limit. Most commonly used.
• Sliding Window Counter: Count requests in the last N seconds using a rolling window. More accurate than fixed window but requires more storage (sorted set in Redis per user).
• Fixed Window Counter: Reset counter every minute. Simple but boundary attack: 100 req in last second of minute 1 + 100 req in first second of minute 2 = 200 req in 2 seconds.
• Distributed Rate Limiting: Use Redis with atomic INCR + TTL. For multi-node: central Redis cluster acts as the rate limit state store. Lua scripts for atomic check-and-increment.

For live data (chat messages, order tracking, stock prices, collaborative docs), polling every few seconds is wasteful. Use persistent connections for server-push.

• WebSocket: Full-duplex persistent connection. Client and server can both send messages anytime. Best for: chat, real-time gaming, collaborative editing, live bidding.
• Server-Sent Events (SSE): Server pushes to client over HTTP. Client can't send back. Best for: live dashboards, order status updates, notification streams. Simpler than WebSocket.
• Long Polling: Client makes request, server holds it open until data is available, then responds. Client immediately makes another request. Simple fallback when WebSocket isn't available.
• Connection management at scale: Each WebSocket connection is a stateful socket. 1M concurrent connections need ~1000 servers (1K connections/server is typical). Use a connection service with Redis for routing messages to the right server.

When users type a query and need to find matching documents across millions of records, traditional SQL LIKE queries don't scale. Use a search engine with an inverted index.

• Inverted Index: Maps each word → list of documents containing that word. Query "red sneakers" → intersect documents containing "red" and documents containing "sneakers".
• Elasticsearch: Distributed inverted index built on Lucene. Handles full-text search, faceted filtering (price range, brand), geo-spatial queries, and aggregations.
• Relevance Ranking: TF-IDF (term frequency × inverse document frequency) as baseline. Layer on: freshness boost, personalisation signals, click-through rates.
• Synchronization challenge: Primary data lives in MySQL/PostgreSQL. Sync to Elasticsearch via CDC (Change Data Capture) with Debezium → Kafka → Elasticsearch consumer. Eventual consistency is acceptable for search.
• Spell correction: Edit distance (Levenshtein) for "did you mean?" features. Trie for autocomplete prefix matching.

In distributed systems, network failures cause retries. Without idempotency, a retry can cause double charges, duplicate orders, or double sends. Every financial/critical operation must be idempotent.

• Idempotency Key: Client generates a unique key per operation (UUID). Server stores processed keys in Redis with TTL. On retry with same key: return cached result instead of reprocessing.
• Pattern in Payment: Client sends POST /payment { amount: 100, idempotency_key: "uuid-123" }. Server processes payment and stores uuid-123 → {success, txn_id}. On retry: return the stored result — no double charge.
• Exactly-Once in Kafka: Kafka supports exactly-once semantics (EOS) via transactions. Producer assigns a transactional ID; broker tracks processed offsets. Consume-transform-produce pipeline is atomic.
• Saga Pattern: For distributed transactions across services (order → payment → inventory), use a saga: sequence of local transactions with compensating transactions on failure. Avoids distributed locks.

When a user posts content that needs to appear in all their followers' feeds, you face the fan-out problem. Two strategies, each with trade-offs.

• Fan-out on Write (Push): When user A posts → immediately write to all followers' feed caches. Pro: fast feed reads. Con: huge write amplification for celebrities (Sachin Tendulkar has 20M followers — one tweet = 20M cache writes). Solution: hybrid approach below.
• Fan-out on Read (Pull): When user reads feed → fetch posts from all followees in real-time. Pro: simple writes. Con: slow reads for users following many people.
• Hybrid (used by Twitter/Instagram): Fan-out on write for regular users (<1K followers). Fan-out on read for celebrity accounts (verified/high-follower users). Merge the two at read time.
• Timeline Cache: Pre-built feed stored in Redis sorted set (post_id + timestamp as score). Feed read = ZREVRANGE on the sorted set. Extremely fast.

Finding the nearest driver, restaurant, or store requires efficient geo-spatial queries. Standard SQL queries on (lat, lng) don't scale — you need spatial indexing.

• Geohash: Encode (lat, lng) into a short string (e.g., "ttnq"). Nearby points have similar prefixes. Redis supports geohash natively: GEOADD, GEODIST, GEORADIUS.
• Quadtree: Recursively divide the map into 4 quadrants. Each node represents a region. Leaf nodes hold location data. Good for static data; expensive to update for moving objects.
• Real-Time Location Updates: Driver sends GPS location every 5 seconds → Kafka → Location service → Redis geohash. Rider app queries Redis for drivers within N km. For 1M drivers: 1M updates/5s = 200K writes/sec to Redis — use Redis Cluster.
• Proximity Search on Maps: Grid-based partitioning → divide the city into N×N cells. Assign entities to cells. Query: find all entities in current cell + adjacent 8 cells.

Distributed systems need globally unique IDs for orders, users, transactions. Auto-increment in a single DB doesn't scale. UUID is unique but not sortable by time.

• UUID v4: 128-bit random. Guaranteed unique globally. Downside: not sortable by time, large storage, bad for DB index locality.
• Twitter Snowflake: 64-bit ID = 41 bits timestamp + 10 bits machine ID + 12 bits sequence. Sortable by creation time. 4096 IDs/millisecond per machine. Used by Twitter, Discord, many others.
• ULID (Universally Unique Lexicographically Sortable ID): 128-bit, URL-safe, sortable. Better than UUID for databases — maintains insert locality.
• Clock Skew Problem: NTP drift can cause two machines to generate the same Snowflake ID. Solutions: use a logical clock, or a centralized ID service (expensive but safe).
• Instagram Approach: Postgres stored procedure generates IDs using epoch + shard ID + sequence. Avoids centralized bottleneck while maintaining sortability.

In microservices, one slow service can cascade failures across the entire system. Circuit breakers prevent this — they stop calling a failing service and return a fallback response instead.

• Circuit Breaker States: CLOSED (normal) → OPEN (too many failures, fast-fail all requests) → HALF-OPEN (let a few through to test if service recovered).
• Failure Threshold: Open circuit when error rate > N% in last M requests, or when last N requests all failed.
• Fallback Strategies: Return cached result (stale but available); return a default/empty response; return a simplified response; redirect to a backup service.
• Timeout: Never let a service call run indefinitely. Set timeouts at every layer (HTTP client timeout, DB query timeout, Kafka consumer timeout).
• Bulkhead Pattern: Limit the thread pool size for each downstream service. If service A is slow, it can only consume its allocated threads — it won't starve calls to services B and C.

Analytics and ML features need both real-time data (for live dashboards) and historical data (for trend analysis, model training). Lambda Architecture handles both.

• Lambda Architecture: Batch layer (historical accuracy) + Speed layer (real-time, approximate) + Serving layer (merges both). Pro: robust. Con: dual code paths, complex maintenance.
• Kappa Architecture: Stream-only with reprocessing. Keep all events in Kafka (long retention). Reprocess historical data by replaying from the beginning. Simpler but requires Kafka storage for months/years.
• Batch Processing: Apache Spark (large-scale ETL, daily reporting). Run nightly or hourly. High latency but can process petabytes.
• Stream Processing: Apache Flink or Spark Streaming (real-time analytics). Process events as they arrive. Use for: live dashboards, real-time fraud detection, surge pricing.
• Data Lake vs Data Warehouse: Lake = raw events in S3/HDFS (schema-on-read, cheap, flexible). Warehouse = processed, structured data in Redshift/BigQuery (schema-on-write, fast queries, expensive).