Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
Tech Mahindra · System Design
Practice System Design questions specifically asked in Tech Mahindra interviews – ideal for online test preparation, technical rounds and final HR discussions.
Questions
45
Tagged for this company + subject
Company
Tech Mahindra
View company-wise questions
Subject
System Design
Explore topic-wise practice
Go through each question and its explanation. Use this page for targeted revision just before your Tech Mahindra System Design round.
Hot spots happen when keys are sequential or skewed. Hashing spreads load evenly across shards. If locality is needed, combine a coarse bucket with a hash suffix to balance.
shard = hash(user_id) % N
For complete preparation, combine this company + subject page with full company-wise practice and subject-wise practice. You can also explore other companies and topics from the links below.
Derive modules, interfaces, and data transfer objects. Pick patterns (e.g., Strategy, Adapter) to isolate variability. Define class responsibilities and contracts per SOLID. Add sequence diagrams for critical flows, error handling, retries, and idempotency. Specify test seams and feature flags to release safely.
HLD frames the system: external contracts, data choices, consistency, partitioning, and resilience. LLD zooms into classes, patterns, and method-level details that realize those contracts.
Model ElevatorCar, Door, Motor, Controller, Scheduler, and RequestQueue. Use a scheduler Strategy (e.g., SCAN/LOOK) to assign calls to cars. Each car runs a finite state machine: Idle, MovingUp, MovingDown, DoorOpen, Maintenance. Ensure safety with debounced sensors and command queue. Expose events for logging. Keep car state isolated; only the scheduler coordinates inter-car decisions.
enum State{IDLE,UP,DOWN,OPEN}
interface Scheduler{ assign(call:HallCall): CarId }Write-through persists to the database and updates the cache in the same flow, trading latency for freshness. Write-back queues DB persistence and can batch writes for speed, but risks data loss on cache failure without durable write logs.
writeThrough(k,v){ db.put(k,v); cache.set(k,v,ttl); }Composite treats individual objects and compositions uniformly. A leaf and a node share the same interface, so traversal and operations look the same. This simplifies tree operations like total price, permissions, or counts. You avoid special-case code for leaves versus groups and add new node types without breaking callers.
interface Node{ total(): number }
class Item implements Node { total(){ return price; } }
class Bundle implements Node { total(){ return sum(children.total()); } }Seek uses a “where key > lastKey” predicate. The index can resume quickly without scanning skipped rows. It is stable and efficient but requires a deterministic order and a resume token.
SELECT * FROM posts WHERE id < :cursor ORDER BY id DESC LIMIT 20;
Namespace keys by tenant and enforce auth at the edge so private responses do not leak to shared caches. Use Vary headers to separate cached variants by auth token or role when using CDNs. Encrypt sensitive payloads at rest in the cache and avoid caching personal data unless necessary. Add strict cache-busting rules on logout or permission changes.
key = tenantId + ":user:" + userId + ":profile:v2"
Honor Retry-After and jittered exponential backoff. Batch small calls, use conditional requests and caching, and avoid parallel stampedes on the same resource. Pre-fetch sparingly and cancel in-flight requests when the user navigates away. Show clear UI messages on throttling and degrade gracefully by hiding non-critical widgets until allowance refreshes.
delay = base * 2^attempt + jitter(); sleep(delay);
Broker fan-out publishes a single event to a topic which multiple consumer groups read independently. It is simple, scalable, and supports replay. The trade-off is eventual consistency and independent failure domains that you must monitor. Application fan-out has the service call each downstream synchronously. It gives immediate feedback but couples latency and availability. A middle ground is to publish once and have a small orchestrator for time-critical side effects.
publish(order.created); // groups: search, analytics, email
Services map to capabilities and can scale, release, and evolve independently. The trade-offs are operational complexity, network calls, and data consistency across boundaries.
Composition means the part cannot live without the whole. Destroying the whole destroys its parts. Aggregation is a weaker “has-a” relationship where parts can exist independently.
Order ◼─ contains ─► OrderItem
State machines capture valid states and allowed transitions. They reduce invalid transitions and make edge cases explicit. Use them for orders, tickets, or workflow engines to prevent illegal jumps.
Pending -> Paid -> Shipped -> Delivered -> Closed
Use composition when an Order strictly owns its OrderItems. Deleting the Order deletes its items. This encodes lifecycle rules in the model itself and prevents orphan records. Use aggregation for looser ties, like Order referencing a Customer that exists independently. This keeps identity boundaries clear and avoids unintended cascading deletes.
Order ◼─ OrderItem (composition) Order ◇─ Customer (aggregation)
Builder separates construction steps from representation. It hides order and defaults while keeping the product immutable at the end. It is ideal for configuration heavy objects, request payloads, and query builders.
User u = new User.Builder().name("Ana").email("a@x").build();A Facade gives a coarse, task-oriented entry point that hides subsystem complexity. An Adapter changes the shape of a single API. Use Facade to standardize flows like onboarding or payment capture across many steps.
class PaymentFacade { charge(){ auth(); capture(); receipt(); } }Strategy lets you swap algorithms at runtime behind one interface. State changes behavior by switching internal state objects based on lifecycle. The wiring is similar, but the trigger and semantics differ: choice vs lifecycle.
price = pricingStrategy.apply(cart); state = state.next(event);
Public feeds and catalogs often tolerate minor staleness. Use caches and ETag/Last-Modified to cut load and latency. Expose freshness headers so clients know what they got and can retry when needed.
GET /items If-None-Match: "etag123"
CDNs push bytes closer to users and absorb traffic spikes. They reduce origin load and tail latency for assets or cacheable API responses. Use cache keys, TTLs, and invalidation paths that reflect personalization and auth.
Cache-Key: path + query(normalized)
Use a primary with at least one replica in a different zone. Enable synchronous or semi-sync replication per RPO. Health checks drive automatic failover via a coordinator or managed service. Test failovers. Make app connections use a discovery endpoint that flips during incidents. Keep idempotency in writers to survive retried transactions.
DB endpoint -> read/write router -> primary/replicas
A focused class is easier to change and test. If its reason to change is “how we charge,” it stays cohesive and stable. Auxiliary work like email or invoicing belongs to separate collaborators invoked by higher-level flows.
class ChargeProcessor{ charge(req:ChargeRequest): ChargeResult }A repository abstracts how aggregates are loaded and saved, so domain code stays persistence-agnostic. It also centralizes queries and caching policy. Keep its interface narrow and aligned with aggregate boundaries to avoid an anemic domain.
interface OrderRepo{ byId(id:Id): Order; save(o:Order): void }Cache-Control sets TTL and cacheability. ETag or Last-Modified enables conditional GETs to validate content cheaply. CDNs and browsers use these signals to reduce origin load.
Cache-Control: public, max-age=300 ETag: "a1b2c3"
Machine-parsable logs with request id, user id, and key parameters let you join events across services. This shortens time to root cause. Sample at edges if volume is high, but always keep errors and slow traces.
logger.info({cid, userId, action:"CreateOrder"})If two services share a schema, any change can ripple across teams. Owning data per service enforces encapsulation and forces collaboration via APIs or events. This improves autonomy and versioning. It also makes zero-downtime migrations easier within each boundary.
orders-db owned by Orders; payments-db owned by Payments
Gateways offload cross-cutting concerns: authentication, throttling, request shaping, and routing. They also help with canary traffic and header normalization. Do not overstuff business logic at the gateway. Keep it a control point, not your application.
Gateway → /v1/orders → OrdersSvc; JWT verify; 429 on quota
A modular monolith can be fast to build, test, and deploy. You avoid distributed failure modes and can refactor across module boundaries easily. Use strong module boundaries to delay the need for microservices until scale or autonomy truly demand them.
Single repo, single process; modular packages; one deployment
Emit domain events from the source service and consume them to build a read model in the target. Use an event log or stream that guarantees at-least-once delivery, and make consumers idempotent to handle duplicates. Store consumer offsets, monitor lag, and expose reconciliation jobs to fix drift. For replays, rebuild the view by re-consuming from the beginning or by bulk snapshot plus tailing new events.
orders → event: OrderCreated → search-indexer builds denormalized doc
TTL bounds staleness and is simple to operate. As the system matures, add targeted invalidation when specific writes must reflect quickly. Full flushes are blunt and risky during peak traffic.
SET key value EX 300 // 5 minutes
Maintain a single-flight lock per key so only one worker recomputes on expiry. Serve stale-while-revalidate for a short window so users get a recent snapshot while refresh happens. Add jitter to TTL to spread expiries and pre-warm at scheduled times. Keep a fast fallback like a smaller top-N precompute to degrade gracefully if both cache and origin are slow.
if(nearExpiry && !lock.held(k)) spawnRefresh(k); return cachedOrStale(k);
Feeds tolerate short-term inconsistency more than write rejection. Accepting writes keeps the product responsive. Background processes repair or order events later, while clients show freshness hints.
Write → log append locally → async replicate → reconcile ordering
CRDT types define associative, commutative, and idempotent merge operations. Divergent states can be merged deterministically to the same result across replicas without coordination.
G-Counter: state = vector; merge = element-wise max; value = sum
Leaderless systems accept writes to multiple replicas and reconcile on reads or via background repairs. Leader systems centralize ordering through a single primary but need failover when it dies.
Client writes to N replicas with W quorum; read reconciles with R quorum
Money transfers and inventory holds for limited stock often choose CP. If replicas cannot agree, the system rejects or blocks requests rather than risk double spending or overselling. Users may see a retry prompt, but data stays correct. You reduce blast radius and avoid costly reconciliation later.
Reserve(item): if quorum fail → 409 or retry after
Range partitions let the engine skip entire partitions for queries like last 7 days or Q2 2025, reducing I/O. Hash partitions are better for even distribution of random writes but offer less pruning for temporal scans.
PARTITION BY RANGE (event_date) (p2025q1, p2025q2, ...)
Co-locating related entities under the same shard key keeps most reads single-shard and cheap. For read patterns that still span shards, build denormalized views or a search index. Heavy multi-shard joins are brittle at scale; push them to batch pipelines or OLAP systems.
Order + OrderLines share shard key = order_id
A single logical index may receive updates from many data shards, creating skew and coordination cost. Maintaining global order and atomicity is complex. Common mitigations: local per-shard indexes plus scatter-gather reads, or an async global index with eventual consistency.
email→user_id index shard must absorb writes from all user shards
Track per-shard QPS, p95 latency, storage, and hot-key frequency. Alert on deviations from the median and on sustained hotspot ratios. Sample keys of top contributors to locate bad partition choices. To fix, add virtual nodes, change the hash function with a remap table, or split hot keys using salting. Run an online rebalancer that backfills and then flips routing gradually.
metrics: shard_qps, shard_p95_ms, top_keys{key,qps}A sliding log keeps each request time and trims those outside the window. The current count equals items within the last W seconds. It is accurate but costs more CPU and memory. A compromise is a rolling window with a few sub-buckets, which balances accuracy and efficiency.
ZADD user:req now now; ZREMRANGEBYSCORE user:req 0 now-W; ZCARD user:req;
WFQ partitions capacity across tenants so no single client starves others. Weights reflect paid tiers or SLAs. This keeps latency predictable and isolates noisy neighbors.
enqueue(tenant, req); scheduleNextByWeight();
Put coarse, cheap checks at the edge to drop obvious abuse close to the user and save bandwidth. Enforce authenticated, precise quotas in the app or gateway where identity is known. Use shared keys and bloom filters to communicate hot offenders to edges quickly. Keep the source of truth in one control plane to prevent drift. Propagate policy and counters via quick, eventually consistent channels with periodic reconciliation.
Edge: IP burst shield; App: per-key token bucket + daily quota
Streams maintain order within each partition. Hash routing by an entity key (e.g., user_id or order_id) ensures all related events land on the same partition and keep order. Global order across partitions is not guaranteed and rarely needed.
partition = hash(order_id) % N
After max retries or non-retryable errors, messages move to a DLQ. Operators can inspect payloads, fix data or code, and replay safely. DLQs prevent poison messages from blocking partitions indefinitely.
onFail>k: if attempts>=k → publish(msg) to DLQ
You still may receive duplicates, but if your consumer writes are transactional and idempotent, the final state reflects one logical application of each message. Use idempotency keys, upserts, or dedupe tables to enforce this.
UPSERT into processed_keys(key); if conflict → skip side effects
If a key is often requested but absent, a short-lived negative cache avoids repeated origin hits. Keep the TTL small so creation appears quickly. This is common for DNS and user lookups where non-existence is frequent.
if(db.miss) cache.set(k, NULL, ttl=10s);