System design interview preparation.

System design is the process of choosing components, data flows and trade-offs that meet a product's requirements. It starts with what users need and the scale and failure conditions the system must handle. A design is easier to evaluate when assumptions are explicit instead of hidden behind a list of technologies.

Monolith vs modular monolith vs microservices?

A monolith is deployed as one application, a modular monolith keeps clear internal feature boundaries within that deployment, and microservices are independently deployable services. These choices affect how teams change code, scale workloads and handle failure. Microservices reduce some coupling but introduce network calls, distributed data and operational coordination.

What are layered, clean and hexagonal architecture?

Layered architecture separates responsibilities such as HTTP handling, business rules and persistence. Clean and hexagonal architecture emphasize keeping core business decisions independent of frameworks and external systems. Ports describe what the core needs, and adapters implement those contracts for a particular database or service.

What are DDD, SOLID and dependency inversion?

Domain-driven design models software around business concepts and their boundaries. SOLID is a group of design principles for keeping responsibilities focused and dependencies manageable. Dependency inversion is one of those principles: high-level business policy depends on an abstraction rather than a particular low-level implementation.

What makes a good REST API?

A REST-oriented API exposes resources through consistent HTTP operations and representations. A useful API contract explains identifiers, input rules, outcomes, errors and pagination so clients do not need to guess. The goal is predictable behavior and evolvable interfaces, not forcing every business operation into a simplistic CRUD shape.

How do I choose SQL vs MongoDB?

Relational databases organize data into related tables with constraints, while MongoDB organizes records as documents that can embed related values. The choice should follow transaction boundaries, relationships, queries and operational needs. Both can scale and both can fail under poor data modeling or inefficient access patterns.

Vertical vs horizontal scaling?

Vertical scaling adds resources to one machine, while horizontal scaling adds machines and distributes requests or data. Horizontal scaling improves capacity only if work can be shared without losing correct state coordination. Stateless request handlers are easier to spread, but databases, sessions and background work may still need special handling.

Cache, CDN, replica or shard: which solves what?

Caches, CDNs, replicas and shards address different kinds of repeated work or load. A cache reuses a result, a CDN brings cacheable content closer to users, a replica copies data, and a shard owns a subset of data. Combining them requires freshness, routing and recovery rules rather than simply adding more boxes.

How does cache-aside work?

Cache-aside means the application manages when values enter and leave the cache. It first looks in the cache, loads missing data from the source of truth, then stores that result for later readers. This reduces repeated database work but creates a separate copy whose freshness must be controlled.

What does CAP actually mean?

CAP describes a limit on distributed systems during a network partition. If nodes cannot communicate, the system cannot guarantee both a single up-to-date view of data and a successful response to every request to non-failing nodes. It must sometimes sacrifice availability or allow responses that may not satisfy that consistency guarantee.

What is eventual consistency?

Eventual consistency allows copies or derived views to differ temporarily while updates propagate. If no new changes occur and processing succeeds, those views converge. This is useful when a delay is acceptable, but the product must define what users see during that delay and how failed propagation is repaired.

Queue vs event vs worker?

A queue holds work waiting to be processed, a worker executes that work, and an event describes a fact that already happened. Commands request an action, while events can notify multiple interested consumers. Delivery and acknowledgement rules determine what happens when workers crash or messages are repeated.

How do I design retries and dead-letter handling?

Retries repeat failed work in the hope that a temporary problem has passed. Backoff spreads attempts over time, jitter avoids synchronized retry bursts, and a dead-letter queue stores work that exceeded its retry policy. Without limits, retries can turn a small outage into sustained overload.

What are idempotency and the outbox pattern?

Idempotency makes repeated requests for one logical operation produce one intended effect. The outbox pattern stores an event record in the same database transaction as the business change, allowing a later publisher to send it reliably. These solve related but different failure windows: duplicate work and losing the message between a commit and publication.

How do I handle partial failure across services?

A cross-service workflow can partly succeed because each service commits independently. A saga coordinates local steps and compensating actions to recover when a later step fails. Compensation is a business recovery action, such as refunding a payment, and may not exactly erase every observable effect of the original action.