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
TCS · System Design
Practice System Design questions specifically asked in TCS interviews – ideal for online test preparation, technical rounds and final HR discussions.
Questions
57
Tagged for this company + subject
Company
TCS
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 TCS System Design round.
Start with goals, scale, SLOs, and constraints. Define APIs, data model, and consistency needs. Sketch read/write flows with sequence diagrams and rough capacity estimates. Then address caching layers, storage choice, partitioning, replication, and failure handling. Close with trade-offs, cost, observability, and a phased rollout.
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.
High cohesion keeps related behavior together. Low coupling limits cross-module knowledge. This combo yields modules that are easier to change and scale independently.
Open–Closed says modules are open for extension, closed for modification. You prefer polymorphism, small adapters, or strategy objects. This reduces regression risk and supports A-B variants without invasive changes.
Strategy separates what varies (algorithm) from the context using it. It improves testability and allows feature flags or per-tenant policies without branching everywhere.
Use-case diagrams map users or external systems to the value they seek. They frame scope and non-functional goals without diving into implementation. They are great at aligning stakeholders early and surfacing missing flows before you commit to design choices.
Actor: Customer Use cases: Sign Up, Login, Browse Catalog, Checkout
Start with a Component diagram to show each service, the interfaces it exposes, and the dependencies it consumes like DBs or queues. Keep boundaries crisp and label contracts. Then add a Deployment diagram to map those components onto clusters, regions, and network zones. Show load balancers, API gateways, sidecars, and data replicas to explain resilience and failover.
Components: API, Auth, Catalog, Orders, Payments Deployment: LB -> API pods; DB primary-replica; Queue nodes
Factory Method lets a base class call a creation hook while subclasses decide the concrete type. This removes explicit new calls from high-level code. It improves testability and keeps open–closed extension. You add a new product by adding a new subclass, not by changing callers.
interface Transport { deliver(): void }
abstract class Logistics { factory(): Transport; }
class ShipLogistics extends Logistics { factory(){ return new Ship(); } }Proxy stands in front of a real object. A virtual proxy defers object creation. A remote proxy represents an object in another address space. A protection proxy controls access. It lets you manage cost, latency, and access control without changing clients.
class ImageProxy implements Image { load(){ if(real==null) real=new Image(); real.load(); } }Command wraps an action as an object with execute and optional unexecute. You can queue, log, and replay these objects. This gives you a clear history for audit and a way to reverse certain actions. In a workflow engine, each step becomes a command. You persist commands to durable storage, then rehydrate and re-run after crashes. For undo, each command stores minimal state needed to roll back safely.
interface Command{ exec(); undo(); }
log.append(command.serialize());Prefer explicit versioning, such as URI or header, so clients upgrade on their timeline. Keep backward compatibility for a window. Document changes and provide SDKs where possible. Announce deprecation, surface warnings in responses, and track usage per version. Use canaries and traffic shaping to remove old versions without surprise.
GET /v2/orders Accept-Version: 2
A shared trace ID ties logs, metrics, and spans. You can see where latency accumulates and which hop failed. Make the ID a first-class header and log it on every boundary. Sample smartly to keep cost under control.
X-Correlation-Id: 7e1b... → carried across calls
Write-behind (write-back) updates the cache first and persists to the database asynchronously. Write-through updates both synchronously. Write-around skips the cache on writes but lets reads fill it later.
put(k,v): cache.set(k,v); queue.enqueue({k,v});Dual write keeps both locations consistent during cutover. You can compare read results and switch the router after parity checks. Backfills handle historical data. Once confidence is high, stop writing to the old shard and decommission.
router: write→old+new; read→old until parity flag flips
Clients need remaining tokens and the reset time to back off smartly. Retry-After tells when to try again, especially with HTTP 429 responses. Consistent headers improve client behavior and reduce needless retries.
HTTP/1.1 429 Too Many Requests Retry-After: 13 X-RateLimit-Remaining: 0 X-RateLimit-Reset: 1730
Namespacing with a type and version keeps different shapes separate. Including query-affecting parameters ensures distinct representations map to distinct keys. Avoid bare IDs or ad-hoc keys that collide across feature changes.
key = `${ns}:v${version}:${id}?${paramSig}`Activity diagrams focus on workflow: steps, forks, joins, and guards. They shine for business processes and batch pipelines. Sequence diagrams focus on message ordering between participants.
Start -> Validate -> [ok] Pay || [fail] Notify -> End
Deployment diagrams place services on nodes like containers, VMs, or regions. They also show networks, proxies, and data stores. This clarifies failover, zones, and where to put caches or CDNs.
Region: ap-south-1 Node: k8s cluster -> Pods: api, auth, cache
Dependency shows that a client uses or depends on a supplier element. If the supplier changes, the client may need updates. Keep dependencies minimal to reduce ripple effects and build times.
APIController --> AuthClient
Adapter translates between incompatible interfaces. It protects clients from vendor API churn and allows gradual migration. It is local and minimal. You adapt only the boundary while keeping the core model stable.
class S3Adapter implements BlobStore { put(b){ s3.putObject(b); } }Leaky bucket smooths bursts to a steady drain. Fixed windows are simple but can burst on boundaries; add jitter or sliding windows to improve fairness. Keep limits per user or token and surface headers so clients adapt.
X-RateLimit-Remaining: 137
Wrap the repository with a decorator that checks cache first. On miss, it calls the inner repo, stores the result with a TTL, then returns it. The interface stays the same, so callers do not change. You can stack more decorators for logging or rate limiting. Keep key design, TTL policy, and invalidation strategy explicit so staleness is predictable.
class CachedRepo implements Repo{
get(k){ v=cache.get(k); if(v) return v; v=inner.get(k); cache.set(k,v,ttl); return v; }
}Quick math sets guardrails. Estimate QPS, peak factors, data volume, and network egress. Add headroom for spikes. Numbers expose bottlenecks early, inform partition keys, and drive caching choices.
QPS≈50k, peak×3, avg payload≈2 KB => net ≈300 MB/s
TTL is simple and bounds staleness. Start there to get wins with low risk. Add fine-grained invalidation events when correctness needs are stricter.
SET key value EX 300 // 5 min TTL
Trace the user’s most frequent action end to end. Count network hops, synchronous dependencies, and cache hits. Anything on the p95 critical path gets caching, denormalized views, or precompute. Remove cross-region calls, use connection pooling, and keep payloads small. Everything else can be async off the path.
GET /feed -> CDN -> API -> Cache -> Store
DTOs shape data for the outside world without leaking internal fields or invariants. This lets you version your API safely and keep domain rules inside entities. They also reduce over-fetching and stabilize clients when your domain evolves internally.
class OrderDTO{ id:string; total:number; items:ItemDTO[] }
class Order{ id:Id; money:Money; lines:OrderLine[] }Store the first successful response against the key. On a duplicate request, return the same outcome and avoid double effects. Keep the key scoped per client and per route, and expire entries on a sensible TTL.
result = store.get(key) ?? createOrder(); store.putIfAbsent(key, result);
Attach a version to the aggregate. On update, compare the version; if it changed, reject and let the caller retry with fresh state. This keeps throughput high under low contention and surfaces conflicts when they matter.
UPDATE orders SET ... WHERE id=? AND version=?; -- if 0 rows affected -> conflict
Model failures explicitly as typed errors (e.g., ValidationError, NotFound, Conflict). Service methods return either a result or a failure. This keeps control flow readable and testable. At the boundary, map types to HTTP codes and include stable error codes for clients. Log with correlation id, avoid leaking internals, and keep messages user-friendly for recoverable cases.
Result<T, E extends DomainError> // map to 400/404/409/500 at controller
Define NotificationRequest, Channel (Email/SMS), TemplateEngine, and ProviderClient adapters. Use a queue for async delivery and a RetryPolicy with exponential backoff and idempotent request keys. Store status per message and expose a query API. Keep templates versioned and variables validated at submission; protect providers behind adapters for swap and test doubles.
interface Channel{ send(msg:Message): SendResult }
class RetryPolicy{ nextDelay(attempt): Duration }Boundaries should map to stable business capabilities like Payments, Catalog, or Identity. Each service owns its data and exposes contracts that match its capability. This keeps cohesion high and reduces cross-service chatter. Team alignment can follow these capabilities.
Service: Payments → owns payments, refunds, chargebacks
A saga breaks a write that spans services into a sequence of local transactions with compensating actions. If a step fails, previous steps are undone by compensation. You can orchestrate centrally or choreograph via events. Design idempotent handlers and clear failure semantics.
Reserve inventory → authorize payment → confirm order; else compensate
Prefer additive changes: new fields are optional and defaults are sensible. Use explicit versioning (URI or header) for breaking changes and run multiple versions during the transition. Publish schemas, SDKs, and deprecation timelines. Track per-version usage and remove old versions only after consumer adoption is confirmed.
GET /v2/orders; older clients remain on /v1 until sunset
Cache-aside keeps cache as a best-effort layer. Reads check cache, then DB on miss, and set the cache. Writes go to DB first, then invalidate or set the cache as needed.
v = cache.get(k) || db.get(k); cache.set(k,v,ttl);
Include resource, id, and version or locale to prevent cross-tenant collisions and to allow safe schema evolution. Human-readable segments aid ops and debugging.
cache:user:v2:1234:profile
Cache-aside is simple and cheap for read-heavy workloads with tolerant staleness. On miss, fetch from the database and set the cache with TTL; invalidate on writes. It avoids write amplification but risks cold-start misses. Write-through updates cache and DB synchronously on writes. Reads are more likely warm and consistent with the last write, but write latency is higher. Use write-through when freshness of just-written items matters and write rates are moderate.
cache-aside: get→miss→db→set; write-through: set cache + persist
Negative caching stores the fact that a lookup returned no result to shield the database from repeated misses. Use short TTLs so real new data appears soon. It is useful for user handles, feature flags, or sparse entities where misses dominate. The risk is hiding recent inserts or fixes, so bound TTL tightly and add explicit invalidation on create.
cache.set("user:handle:foo", null, 30s) // miss remembered for 30sConsistency is a single, up-to-date view across replicas. Availability means non-failing nodes return a response. Partition tolerance means the system withstands dropped or delayed messages and still operates.
C: linearizable view A: non-error response P: operation despite partitions
Monotonic reads ensure a client does not see older versions after seeing a newer one. Read-your-writes ensures the writer sees its own updates. Causal preserves happens-before. Eventual gives no strict bound.
Client A sees v2 → later should not see v1 under monotonic reads
Vector clocks track per-process counters. By comparing vectors you can tell if one event happened-before another or if they are concurrent. Lamport clocks give only a partial order.
If v1 <= v2 and not equal → v1 happened-before v2
At-least-once means duplicates can occur. Assign a stable idempotency key per user intent or per message. Consumers record processed keys and outcomes so replays or retries are safe. Side effects become repeatable. This keeps availability high while bounding correctness issues under partitions or crashes.
If key seen → return stored result; else process and store outcome
Use fault injection to drop, delay, and reorder messages. Run Jepsen-style workloads that assert invariants such as no lost updates and monotonic reads per client. Measure replica lag, quorum behavior, and read-your-writes. Add shadow traffic and verify traces across regions. Document observed anomalies and ensure they match your chosen model.
Chaos: partition A|B for 5 min; run writes; validate invariants post-heal
Hashing a high-cardinality identifier spreads load evenly and avoids concentrating traffic on a single shard. Pure time or geography keys can cause skew during spikes or regional events unless combined with hashing.
shardId = hash(user_id) % N
Salting spreads hot writes across multiple shards or partitions by appending a small salt, then merging on read. This reduces contention while keeping query semantics intact with a controlled fan-in.
post:{id}:{salt in 0..9} -> read fan-in 10, merge by timeTwo-phase commit gives atomicity across shards but adds a coordinator, locks, and higher latency. It is suitable when you need strict all-or-nothing semantics on small, infrequent transactions. Sagas split the workflow into local transactions with compensations. They scale better and keep availability high, at the cost of transient inconsistency and more failure handling code. Use Sagas for high-throughput, user-facing operations where partial progress is acceptable with recovery.
Reserve A → Reserve B → Confirm; on failure: Cancel B, Cancel A
Start with configured limits per tenant. Continuously watch downstream p95 latency, queue depth, and error rate. When thresholds breach, reduce allowed tokens proportionally (AIMD or gradient) for all tenants, preserving relative weights. Once metrics recover, gently increase limits. This keeps the system responsive under partial failures while maintaining fairness and honoring premium weights.
if(p95>t || err>e){ limit *= 0.7 } else { limit += step }Introduce a shard-map v2 that maps old slots to new slots (e.g., power-of-two expansion). Start dual writes and begin backfilling data to new shards in batches with throttling. Validate parity by sampling reads from both targets. Switch reads per-tenant or per-bucket using flags. Monitor error rates and lag. Once stable, disable writes to old slots, run a final delta sync, and decommission. Keep rollback by retaining old data and routing map until confidence is high.
slot = hash(key) & 127 // from & 63 to & 127; router supports v1|v2
With fixed windows, a client can send near the end of one window and immediately at the start of the next, effectively doubling the rate for a moment. This can overload downstreams. Sliding window (log or rolling) or token bucket reduces the boundary artifact by smoothing limits across time.
key = user+":"+floor(now/60); INCR key; EXPIRE key 60;
Limiters bound volume; breakers bound failure cascades. They complement each other: throttle before the dependency, and stop calls when the dependency is unhealthy. Together they reduce tail latency and protect shared infrastructure.
if(breaker.open()) failFast(); else if(!limiter.allow()) shed();
Combine identity signals: key, IP/subnet, user agent fingerprints, and behavior features. Apply velocity rules across these dimensions, not just per key. Use progressive challenges (e.g., CAPTCHA or proof-of-work) before hard blocks and add reputation scores that decay over time. Keep allow-lists for partners and offer higher-tier customers dedicated capacity. Always log decisions with reasons for later appeal and model tuning.
score = f(keyRate, ipRate, uaEntropy); if(score>τ) challengeOrBlock();
Networks fail and consumers crash; retries can generate duplicates. At-least-once is practical and robust when consumers are idempotent. Exactly-once exists in narrow, coordinated contexts but is complex and slower. Design handlers to tolerate duplicates and out-of-order events.
if(seen(key)) return storedResult; else process(); markSeen(key)
Exponential backoff reduces coordinated spikes; jitter spreads attempts to avoid thundering herds. A cap limits tail latency and hands off to a dead-letter flow when needed. Always log retry cause and decision for observability.
delay = base * 2^n + rand(0..jitter)
Add fields with defaults and avoid changing meaning. Consumers should ignore unknown fields. For breaking changes, publish a new version key or topic and migrate gradually. A schema registry helps coordinate producers and consumers.
event { v:2, orderId, total, currency? }Define a stable idempotency key per payment attempt (e.g., gateway id). Before side effects, check a 'processed' table keyed by that id. If present, return the stored result; otherwise, perform the operation and record the outcome in the same transaction. Make handlers resilient to retries and out-of-order messages. Keep compensations for partial failures and expose metrics for duplicates, lag, and failure reasons.
BEGIN; if exists(processed,key) return; doWork(); insert(processed,key); COMMIT;
Keep events small: publish metadata and a pointer to object storage. Consumers fetch the blob when needed, with signed URLs and short TTLs. Add server-side compression and chunking for rare large items. Introduce quotas and reject oversize messages early. For hot objects, cache near consumers to avoid repeated downloads and tune prefetch to avoid large in-flight memory.
event: { id, type, s3_url, checksum } // fetch & verify on consumeCache-Aside keeps the cache as a read-through sidecar controlled by the application. It is simple and widely used because it avoids placing the cache on the write path. Consistency relies on disciplined invalidation when underlying data changes.
v = cache.get(k); if(!v){ v=db.get(k); cache.set(k,v,ttl);} return v;TTL bounds staleness regardless of activity. TTI (also called sliding expiration) keeps hot items alive by renewing their expiry on each hit. Combining them allows a hard freshness cap while keeping active keys resident.
set(key,value, ttl=10m, tti=2m)
Strong consistency means reads reflect the latest write. Achieving this via write-through and synchronous invalidation increases latency and coupling; reserve it for critical correctness paths like balances or entitlement checks. Eventual consistency allows brief staleness to gain speed and resilience. Use it for catalogs, feeds, or search where minor delays are tolerable. Bound staleness with TTLs, revalidation, or read-after-write exceptions for the actor who made the change.
readYourWrites(userId, key){ bypassCacheFor(userId,key,window=5s) }