Architecture and system design interview bank

Write an ADR when a decision materially affects system structure, a quality attribute, a dependency or interface boundary, or how several teams work. Costly reversal and multiple credible options are also strong signals. Do not record every implementation detail: a local naming choice belongs in code review, while a temporary operational workaround belongs in a ticket or runbook. The practical test is whether a future maintainer will need the original context, alternatives, and trade-off to change the system safely. Record the decision while that evidence is still available.

Replace an adjective such as scalable or resilient with a stimulus and an observable response. Name the source, event, operating environment, affected system part, expected behavior, and response measure. For a payment timeout, the scenario might require a queryable pending state within two seconds and reuse of one idempotency key, rather than claiming generic availability. A performance target also needs workload, data size, environment, and percentile. This form constrains design choices and tells the team what to test without pretending an unmeasured quality has already been achieved.

A signature describes shape, not the full behavior a caller relies on. A substitute can compile while rejecting an input the base contract accepts, returning a value outside its promised range, breaking a state invariant, or introducing a new failure after a side effect. Those changes strengthen preconditions or weaken postconditions, so callers need subtype-specific branches. Test every implementation through the base interface with one shared contract suite covering boundary inputs, state transitions, results, and failures. Implementation-specific tests add detail but cannot replace that common evidence.

Handle unacceptable security, data-loss, compliance, or active-incident risk first. For the rest, compare recent change frequency, extra effort observed per change, blast radius, remediation range, and uncertainty, with links to evidence. That exposes assumptions instead of hiding them behind arbitrary weights. Static-analysis findings and coverage are investigation signals, not business value by themselves. The disposition can be repay now, bundle with the next related feature, accept with an event-based review trigger, or close as a false positive. Record why the choice beats its opportunity cost and what evidence will close the item.

It protects business policy from knowing delivery and infrastructure details. Source dependencies point inward: a use case may define the repository or presenter contract it needs, while a database or HTTP adapter implements that contract. Runtime calls can cross the boundary in either direction; the rule concerns which module names and imports the other. Data crossing the boundary should use application-owned structures rather than ORM rows or framework request objects. A useful check is whether the core can be tested with simple fakes and changed without importing the web framework, database driver, or message broker.

All three keep application or domain policy independent of replaceable infrastructure through dependency inversion. Clean Architecture emphasizes concentric policy levels and use cases; Onion Architecture emphasizes a domain model surrounded by application and infrastructure layers; Hexagonal Architecture describes inbound and outbound ports implemented by adapters. The drawings and vocabulary differ more than the goal. Do not force a one-to-one mapping between every ring and port. Instead, identify the core policy, name the contracts it owns, place adapters outside, and verify import direction plus boundary data in the actual codebase.

On a Node 24 baseline, an accepted ADR is a historical record, not a mutable description of current architecture. Create a new ADR that states the changed context, compares viable options, and names the replacement decision. Mark the old record as superseded and link both directions; do not reuse its identifier or rewrite its rationale to match current code. Small editorial corrections may be dated amendments only when meaning stays intact. The trade-off is more records, but a queryable index preserves why old commits exist and prevents a stable link from silently referring to a different decision.

In a Node 24 system, connect each important predicted consequence to evidence: an architecture test for import direction, a contract test for compatibility, telemetry for latency, or a recovery exercise for resilience. Record the responsible role, observation timing, and a review trigger such as traffic, regulation, or recovery-objective change. Acceptance means the decision is in force, not that delivery or benefits are complete. Avoid vague consequences such as “more scalable”; they cannot reveal drift. The extra maintenance cost is justified only for material assumptions, so keep validation narrow and retire obsolete checks when a superseding ADR changes the contract.

For a Node 24 application, begin with the decision question and audience. Use a context view for users, external systems, and trust boundaries; a container view for deployable units, protocols, and stores; and a component view for responsibilities and dependency direction inside one container. State scope, date, and omission rules, then label every important relationship with direction and purpose. Mixing classes, cloud resources, and external actors in one picture buries the boundary under detail. A diagram is not enforcement: back important edges with import rules, permissions, or contract tests, and compare the view with deployed evidence as the system changes.

For the Node 24 baseline, rank current quality scenarios and hard constraints, compare the status quo with viable alternatives, and choose the simplest structure that meets them. Mark uncertain growth as an assumption rather than installing queues, services, or replicas preemptively. Then create a feedback loop: automated dependency checks protect stable boundaries, telemetry reveals runtime pressure, and ADR review triggers reopen decisions when evidence changes. The pitfall is optimizing every quality attribute at once; each mechanism adds operating and failure cost. Keep reversible choices local, prototype the riskiest hard-to-reverse assumption, and record what evidence would justify the next structural step.

In TypeScript 6, neither principle requires classes. For SRP, group behavior by actor, invariant, and evidence of co-change from real or committed work; method count is irrelevant. For OCP, add a function, module, or interface boundary only where independent variation has occurred or is scheduled, and define its observable contract. A stable local calculation is clearer left direct. Mechanical splitting creates navigation, injection, and test-double cost while coupling survives between files. Validate the boundary with a realistic second implementation and change scenario; if every change still edits the same modules together, the abstraction has not isolated the reason to change.

In TypeScript 6, a container can hide concrete construction while high-level business modules still import vendor types or service-locator tokens. DIP concerns source dependency direction and contract ownership: high-level policy defines the port in its own language, an outside adapter implements it, and a composition root may know both. Type checking proves shape only. Add contract tests for valid inputs, outputs, state changes, and failures, plus import rules that prevent policy from reaching adapters. The trade-off is another boundary to maintain, so introduce it where technology replacement, test isolation, or independent change is real rather than wrapping every stable helper.

For a Node 24 system, call an item technical debt only when a design or construction choice adds extra cost or risk to a specific future change. Incorrect current behavior is a defect; missing business capability is product work; a smell or coverage number is only a signal until linked to impact. Record the affected change, observed interest such as delay or incidents, principal, target state, owner, and exit evidence. This classification prevents a debt register becoming an unprioritized junk drawer. The trade-off is investigation time, so close false positives when the code is stable, scheduled for removal, or lacks evidence of future change cost.

In a Node 24 codebase, first protect observable behavior with characterization tests and relevant telemetry. Establish a seam at a frequently changing boundary, move one bounded slice, compare outcomes, and retain a tested rollback path. Every temporary adapter, feature flag, or dual-read path needs an owner and deletion condition. Close the debt item only when the target structure exists, external behavior remains valid, and exit evidence shows the legacy path is unreachable. A full rewrite may look cleaner but discards hidden behavior and makes rollback coarse; choose it only when incremental seams are infeasible and migration, reconciliation, and recovery are independently verifiable.

Start with the recurring design pressure, not the pattern name. State what varies, what must stay stable, who owns the change, and what simpler design has failed or become costly. Then compare the pattern’s new indirection, state, allocation, and debugging cost with the coupling it removes. For example, Strategy is justified when several interchangeable policies really change independently; one conditional with two stable branches may be clearer. Validate the choice with a small change scenario and tests. A pattern is shared vocabulary for a trade-off, not a requirement to reproduce a textbook class diagram.

Strategy selects an interchangeable algorithm for a job; the client or composition root usually chooses it, and switching does not inherently represent a lifecycle. State models behavior that changes with an object’s current state, and transitions are part of that object’s rules. Both can delegate through a common interface, so their class diagrams may look alike. Ask who chooses the implementation and whether transitions are domain behavior. Shipping selection among pricing algorithms suggests Strategy. An order moving from pending to paid to canceled suggests State, especially when each transition must enforce allowed operations.

Modules need explicit ownership, public entry points, and data boundaries that ordinary code cannot bypass. One deployment unit does not imply one undivided model. Calls should go through module facades or published events, while direct imports of internals and cross-module table access are prohibited. Enforce those rules with package visibility, import linting, architecture tests, and schema permissions where practical. A shared kernel stays small and changes under joint review. The decisive test is whether one module can evolve or later be extracted without searching the whole repository for hidden calls and shared writes.

A bulkhead prevents one dependency or workload from consuming every shared resource and disabling unrelated work. The isolation must match the scarce resource: separate connection pools, thread or worker pools, queues, concurrency limits, and sometimes process or cell boundaries. Merely placing calls in different classes changes nothing. Size each compartment from measured demand, reserve capacity for critical paths, define overflow behavior, and observe saturation plus rejection. Isolation reduces blast radius but can waste capacity or move contention downstream. For example, separate worker pools do not help if both still exhaust the same database connection pool.

Put a routing seam in front of the legacy capability, choose a bounded slice, and define parity and rollback evidence before moving traffic. Establish one authoritative write path; uncontrolled dual writes create partial-success and ordering failures. If both models need data, propagate changes through an outbox, change-data capture, or a reconciled migration process. Compare shadow reads or business outcomes, then shift traffic gradually while watching errors, latency, and data divergence. Rollback must account for writes accepted by the new path. Remove the old route, synchronization code, and temporary flags only after reconciliation proves the cutover complete.

Give every flag a type, owner, creation date, rollout or experiment metric, safe default, and removal condition. Keep evaluation near a deliberate boundary and make behavior deterministic from a captured flag value during one request. Test both branches while both exist, including failure of the flag service, but do not multiply every test by every unrelated flag combination. After rollout, remove the losing branch, configuration, telemetry, and tests in the same planned cleanup. Inventory checks can alert on expired flags. A kill switch may remain long-lived, but it still needs drills, access control, and review.

First clarify users, core operations, correctness rules, and what is explicitly out of scope. Turn quality goals into measurable load, latency, availability, durability, and freshness targets, then estimate only the numbers that can change the design. Draw the request and data paths, assign ownership of state, and identify the first likely bottleneck or failure boundary. Discuss one baseline before adding caches, queues, replicas, or shards. For each addition, state the pressure it relieves and the new failure it creates. End by revisiting the requirements and naming what you would validate with production evidence.

A gateway should own edge concerns that are consistent across services: routing, TLS termination, authentication enforcement, coarse rate limits, protocol adaptation, request correlation, and sometimes client-specific aggregation. Domain authorization, business validation, and data invariants remain with the service that owns the domain because only it has the required state and semantics. Keep transformations explicit and versioned so the gateway does not become a hidden second application. For a payment request, the gateway can verify a token and quota, but the payment service must decide whether that customer may charge that account and whether the transition is valid.

Define the composed response contract first, separating required data from optional enrichments. Run independent calls concurrently under one end-to-end deadline, propagate cancellation, and give each dependency a smaller budget. Bound fan-out and avoid N+1 calls through batch APIs or purpose-built read models. Decide per field whether failure makes the whole response fail, returns an explicit unavailable state, or uses a freshness-bounded cache; never silently present stale data as current. Measure the critical path, partial-result rate, and downstream load. Retries belong within the same deadline and only on safe, transient operations.

Assume a worker can stop after producing an effect but before acknowledging the message, so the job may run again. Give the logical operation a stable identity, record completion atomically with owned state where possible, and make external effects idempotent or deduplicated. Acknowledge only after durable completion. Classify failures: retry transient ones with bounded exponential backoff and jitter, send permanent or exhausted failures to a visible dead-letter path, and preserve enough context for repair. Timeouts, cancellation, concurrency limits, and observability are part of the contract. Exactly-once business effects come from design, not a queue label.

If any healthy instance can handle the next request, a load balancer can add, remove, or replace instances without preserving session affinity. That makes scaling and recovery simpler, but it does not make the system state-free. Sessions, idempotency records, rate-limit counters, caches, workflows, and business data still live somewhere and need ownership, consistency, capacity, and failure policies. Move durable state to appropriate stores and keep only disposable local caches. For an upload or long workflow, use a stable operation ID so another instance can resume from shared progress instead of depending on one process’s memory.

Independent deployment is valuable when a cohesive business capability has distinct ownership, release cadence, scaling or failure needs, and a stable contract with its neighbors. It is not achieved merely by creating another repository or runtime. Backend services add network failure, data consistency, security, and operations; micro-frontends add asset, routing, shared-dependency, styling, and browser integration risks. Check whether the slice can be built, tested, released, observed, and rolled back without synchronized changes elsewhere. If teams still coordinate every schema, shared package, or page release, the split has moved coupling into deployment rather than removed it.

CAP applies when replicas sharing mutable state cannot communicate. If both sides must complete operations, either side can accept an update the other cannot observe, so the history may stop being linearizable. Preserving linearizability instead requires at least one side to reject or indefinitely delay some otherwise valid operations, giving up CAP availability there. Partition tolerance is best treated as the fault model, not a benefit selected from a menu. The useful design question is which operation and invariant chooses consistency or availability during that partition, because one product can make different choices for different paths.

A timeout bounds each attempt and the caller needs an overall deadline that includes all attempts. Retry only transient failures on operations that are safe to repeat, using backoff, jitter, and a small attempt budget. The circuit breaker observes outcomes for one dependency and operation class; when failures or slow calls cross its threshold, it rejects quickly so resources can recover. After the open interval, allow only limited half-open probes. Do not stack retries independently at every layer, because multiplication can overwhelm the dependency. Measure attempts, rejections, latency, saturation, and final outcomes, then tune from real failure behavior.

Use synchronous communication when the caller needs an immediate answer to continue and can tolerate the dependency in its latency and availability path. Use messaging when work can be accepted and completed later, multiple consumers need the fact, or temporal decoupling matters. Messaging does not remove coupling; it moves it into schemas, delivery semantics, ordering, retries, and lag. State the user-visible contract first. A price check during checkout may be synchronous under a deadline, while sending a receipt can be asynchronous. In either case define timeouts, idempotency, compatibility, ownership, observability, and what the caller sees during failure.

Choose choreography when services react independently to stable domain facts and no participant needs a global view of progress. It keeps the publisher unaware of consumers, but the workflow becomes harder to discover, time out, and repair as the event chain grows. Choose orchestration when sequencing, deadlines, compensation, operator visibility, or an explicit process state are central. The orchestrator should coordinate, not absorb each service’s domain rules. A hybrid is common: an orchestrator manages one bounded workflow and publishes outcome events for other domains. Compare ownership, change coupling, failure recovery, and audit needs rather than event count alone.

Each Saga step commits a local transaction and may expose effects before a later step fails. Compensation is a new business action that semantically offsets an earlier action; it does not erase history or guarantee restoration of the exact prior state. A refund differs from deleting a charge, and a sent email cannot be unsent. Define compensation, idempotency, ordering, deadlines, and manual-repair states for every reversible step before implementation. Persist Saga progress so recovery can resume after a crash. Some effects are irreversible, so the workflow may need reservation, delayed commitment, or explicit customer-facing reconciliation instead of pretending rollback is possible.

Scope the key to the caller and operation, and bind it to a normalized request fingerprint so reusing the key with different input is rejected. Atomically create a record that distinguishes in-progress, succeeded, and retryable or terminal failure states. Concurrent duplicates must converge on that record rather than execute twice. Preserve the status code and response needed to replay the original outcome, while avoiding unsafe secret storage. Define retention from the client’s retry window and business risk. The key protects one server operation; downstream side effects still need the same operation identity, an outbox, or their own deduplication boundary.

Assign each tenant or workload to a cell with a stable mapping, and keep the routing tier stateless with respect to business data. Discovery and health checks can tell routers which endpoints are eligible, but a healthy registry entry does not prove that a request will succeed, and observations can lag. Use request deadlines, readiness criteria, and cell-level saturation signals. Do not automatically spill all traffic from a failed cell into healthy cells; that can exhaust them and erase the blast-radius boundary. Failover requires compatible data, reserved capacity, an explicit policy, and tests for stale mappings during reassignment.

Intersecting read and write quorums can ensure that a read contacts at least one replica involved in a completed write, but arithmetic alone does not define which value wins. The protocol still needs versions or terms, a rule for concurrent writes, correct membership, and a way to reject stale leaders. Sloppy quorums and hinted handoff may deliberately contact replicas outside the preferred set, weakening the simple intersection argument. State the consistency contract first, then verify the full protocol under message delay, retries, crashes, reconfiguration, and partition recovery rather than citing R + W > N as a proof.

If both sides accept writes during a partition, reconnection exposes concurrent histories rather than automatically restoring one correct value. The design must define conflict detection, merge semantics, tombstone retention, repair ownership, and the user-visible state while replicas converge. Last-write-wins is a policy, not neutral recovery; clock skew can discard a valid update. Some data can merge with a CRDT, while invariants such as unique reservations may require compensation or coordination. Test repeated partitions and retries, preserve idempotency identifiers, and monitor unresolved conflicts so eventual convergence is an operational commitment rather than a slogan.

A bounded context defines where one model and ubiquitous language have a consistent meaning. It is a semantic boundary first; deployment is a separate choice. The same word can legitimately mean different things across contexts, so integration needs an explicit mapping rather than a shared universal entity. For example, Customer may mean a credit relationship in billing and a recipient profile in shipping. One context can begin as a module, while one service may temporarily host several contexts. Discover the boundary from language, rules, ownership, and change patterns, then choose process and data boundaries based on operational needs.

Group only the entities and value objects that must satisfy a business invariant in one atomic transaction, and expose changes through the aggregate root. Reference other aggregates by identity and coordinate cross-aggregate work through application logic, domain events, or a process manager. A large object graph is not evidence for one aggregate; oversized aggregates create contention and force unrelated data to load together. For an order, line quantities and the order total may need one boundary, while customer credit can belong elsewhere. Test commands against concurrent changes and state explicitly which consistency is immediate and which is eventual.

Use a domain primitive when a scalar has business meaning, validation, normalization, units, or security rules that should travel together. Construct it through one validated path, keep it immutable, and expose operations in domain language. EmailAddress prevents unvalidated strings from crossing the boundary; Money can require a currency and forbid accidental addition across currencies. Do not wrap every scalar mechanically. A type adds value when it makes invalid states harder to represent or prevents argument mix-ups. Parsing external input can return a structured failure, while code inside the domain works only with an already valid value.

Name a completed domain fact in past tense and include a stable event ID, occurrence time, aggregate identity, and the business data consumers need. Keep the payload immutable and evolve its contract compatibly. Raising an event in an aggregate is not the same as reliably publishing it: commit owned state and an outbox record atomically, then publish with retries. Consumers still deduplicate by event ID and handle delayed or out-of-order delivery. A handler should not reach back into the producer for data that defined the fact, because that creates temporal coupling and may observe a newer state.

It should reveal a shared timeline of domain facts, the commands and actors that cause them, policies that react, external systems, important read models, and hotspots where participants disagree or lack evidence. Hotspots are valuable outputs, not defects to hide. Use language changes, policy ownership, and consistency needs to propose context and aggregate boundaries, but treat those boundaries as hypotheses. Capture unresolved questions, owners, and experiments after the workshop. The colored notes are not an implementation design by themselves. Validate the model against real scenarios, exceptions, and domain experts before translating it into services, schemas, or classes.

CQRS separates the model that accepts commands from models optimized for queries. Event Sourcing stores accepted state changes as an append-only event history and rebuilds current state by replay. They fit together because the event stream can feed read projections, but neither requires the other: CQRS can use ordinary transactional tables, and an event-sourced aggregate can serve simple reads without a separate query model. Choose them for separate pressures. CQRS introduces projection lag and rebuild operations; Event Sourcing introduces event evolution, replay determinism, storage growth, and correction workflows. Snapshots accelerate replay but are derived data, not the authoritative history.

Emit a stable event name, severity, timestamp, service and version, operation or correlation identifiers, and structured fields needed to explain the outcome. Log at ownership boundaries rather than logging and rethrowing the same failure at every layer. Include trace and span IDs when available, but keep logs independently searchable. Never record passwords, tokens, private keys, or raw sensitive payloads; classify and redact fields before emission, not only in the log backend. Control high-cardinality values and volume so incidents do not make logging unaffordable. A useful event supports a concrete diagnostic question without reconstructing prose.

Instrumentation creates a span for each meaningful operation and propagates trace identifiers plus sampling information through supported request or message metadata. The receiver extracts that context, validates it, and starts a child or linked span as appropriate; asynchronous fan-out may need links rather than pretending one strict call stack exists. Do not propagate baggage indiscriminately, because it adds bytes, cardinality, and possible sensitive data across trust boundaries. Sampling must preserve enough end-to-end decisions to assemble useful traces. Record errors and key attributes with bounded cardinality, and use logs or metrics for details traces are not designed to carry.

Return a stable machine-readable code, safe human message, relevant field details, and a correlation identifier, with an HTTP status that reflects the protocol outcome. Do not expose stack traces, SQL, dependency addresses, secrets, or unstable exception class names. Internally, classify expected operational failures separately from programming defects, preserve the cause chain, and log structured context once at the boundary that owns handling. Map domain failures deliberately instead of turning every exception into 500. For an unexpected failure, give the client a generic retry policy and correlation ID while sending detailed diagnostics and alerts only to controlled systems.

Start with a measurable steady-state hypothesis tied to user or business behavior, then inject one realistic failure whose scope and duration are controlled. Define abort conditions, responsible operators, rollback, excluded critical periods, and the smallest useful blast radius before starting. Observe the user outcome and system mechanisms, not merely whether the injection tool ran. A latency experiment might predict that checkout success stays above its agreed threshold while one dependency slows. If the hypothesis fails, stop, preserve evidence, fix the weakness, and rerun. Repeated safe experiments validate resilience; unbounded random breakage only creates incidents.

A mesh data plane can observe transport-level requests passing through its proxies and emit consistent connection, latency, response-code, retry, and mutual-TLS telemetry. Its control plane distributes routing, security, and telemetry configuration; it is not on the normal data path. This view cannot reliably infer business success, tenant impact, queue work, local calls, or traffic that bypasses capture. Encrypted or streaming protocols may also limit semantic detail. In Istio, verify workload enrollment, traffic capture, protocol detection, sampling, and label cardinality. Add application metrics and spans for domain outcomes, and budget the mesh’s latency, resource, and operational cost.