Architecture and Technical Trade Offs Questions

Centers on system and solution design decisions and the trade offs inherent in architecture choices. Candidates should be able to identify alternatives, clarify constraints such as scale cost and team capability, and articulate trade offs like consistency versus availability, latency versus throughput, simplicity versus extensibility, monolith versus microservices, synchronous versus asynchronous patterns, database selection, caching strategies, and operational complexity. This topic covers methods for quantifying or qualitatively evaluating impacts, prototyping and measuring performance, planning incremental migrations, documenting decisions, and proposing mitigation and monitoring plans to manage risk and maintainability.

EasyBehavioral

35 practiced

Tell me about a time you had to choose between delivering a feature quickly and designing a cleaner, more extensible architecture. Describe the decision you made, the trade-offs you considered, how you communicated the risks, and what you learned.

MediumTechnical

31 practiced

Compare relational (SQL) and document/key-value (NoSQL) databases for two use cases: (a) user authentication/session storage, and (b) analytics of user behavior. For each use case recommend one database type and explain the trade-offs in terms of consistency, queryability, operational complexity, and cost.

HardSystem Design

38 practiced

You are responsible for observability design for a large service-oriented system. Create an end-to-end plan that uses logs, metrics, and traces to detect performance regressions or correctness bugs introduced by an architecture change. Include instrumentation points, alerting rules, dashboards, and runbook entries.

Sample Answer

**Overview & goals**Design an end-to-end observability plan so an architecture change (e.g., moving auth to a sidecar or changing DB topology) is quickly detected for performance regressions or correctness bugs, and actionable for on-call SREs.

**Instrumentation points**- Front-door (API gateway): request latency, status codes, request size, trace entry/exit, sampled headers.- Service boundaries: HTTP/grpc client + server spans with resource tags (service, version, deploy-id, route).- Datastore layer: query latency histograms, error counts, pool utilization, slow-query logs.- Messaging/queues: enqueue/dequeue latency, backlog size, delivery failures.- Hosts/containers: CPU, memory, disk IO, network, thread counts, GC pause.- Business correctness logs: structured events for critical state transitions (order created/paid/shipped) with correlation IDs.

**Traces**- Distributed tracing with 100% header propagation; sample 5-20% of traffic, 100% for errors and transactions exceeding latency SLO.- Tag spans with deploy-id, feature-flag, request-type to compare before/after.

**Metrics & SLOs**- Key metrics: p95/p99 latency, error rate %, throughput, DB query latency p99, queue backlog.- Define SLOs (e.g., 99th percentile latency ≤ 500ms, error rate ≤ 0.5%).- Maintain error budget and burn-rate alerts.

**Alerting rules**- Severity P0: error rate > 1% for 5m OR traffic-weighted p99 latency > 2x baseline for 5m.- P1: sustained p95 latency > SLO for 10m OR queue backlog growth > 30%/10m.- P2: host resource > 85% CPU or DB connections > 90% for 15m.- Trace-based alert: spike in traces with same exception type or new exception not in baseline.

Each alert includes context: top affected services, recent deploy-id, example trace IDs, runbook link.

**Dashboards**- Change-focused dashboard: rollout deploy-id selector; shows pre/post comparison of latency percentiles, error rates, throughput, DB latency, top traces, top error messages.- Service health dashboard: per-service SLOs, resource metrics, top slow endpoints.- Dependency map: heatmap of downstream latency and errors.

**Runbook entries (on-call playbook)**- Step 1: Acknowledge alert; check deploy-id and recent architecture change.- Step 2: Open change dashboard, filter to deploy-id, identify top failing endpoints and example trace IDs.- Step 3: If errors show new exception: inspect code path, feature flag, roll back or disable flag.- Step 4: If latency: compare span timings to find hot dependency; throttle traffic or rollback; scale DB/worker if resource-constrained.- Step 5: If unclear, capture full traces (increase sampling for affected traffic), collect structured logs, tag incident, escalate to dev owning service.- Post-incident: run RCA, add synthetic tests, update alerts thresholds or instrumentation gaps.

**Validation & CI**- Add canary + synthetic tests that exercise critical paths; compare baseline metrics during canary rollout automatically.- Run chaos tests on non-prod to validate alerts and runbooks.

This plan prioritizes correlation (logs+metrics+traces), deploy-aware tagging, SLO-driven alerts, and clear, actionable runbooks so an architecture change is detectable and resolvable quickly.

MediumSystem Design

28 practiced

Given a service-level requirement of 99.99% availability for a critical API, describe the architectural components and patterns you would include (redundancy, health checks, failover, replication, circuit breakers). Explain trade-offs in complexity, cost, and operational burden, and identify single points of failure that remain.

HardTechnical

30 practiced

A service is throughput-limited. Using Little's Law and queueing concepts, explain how you'd decide between vertical scaling (bigger instances) and horizontal scaling (more instances). Provide a simple calculation example showing how arrival rate, service time, and concurrency affect the decision.

Sample Answer

**Approach (short)** I’d use Little’s Law to relate concurrency, throughput and latency and basic queueing (utilization) to see whether CPU/IO on a single instance is the bottleneck (vertical) or if adding replicas will reduce wait and increase throughput (horizontal).

**Little’s Law**

text

L = λ * W

L = average number in system (concurrency), λ = arrival rate (requests/sec), W = average time in system (sec).

**Queueing / Utilization (M/M/1)**

text

ρ = λ * S

ρ = utilization, S = service time (sec). System unstable if ρ ≥ 1.

**Decision factors**- If ρ close to 1 on CPU/worker threads → vertical scaling may immediately reduce S, lowering ρ. - If app is stateless and easily sharded → horizontal scaling gives linear capacity until other resources (DB, network) limit. - Consider cost, deployment complexity, statefulness, and downstream bottlenecks.

**Concrete example**- Arrival λ = 200 req/s - Current avg service time S = 0.004 s (4 ms) → ρ = 200 * 0.004 = 0.8 (80% util) - Concurrency L = λ * W; W ≈ S/(1-ρ) for M/M/1 → W ≈ 0.004 / 0.2 = 0.02 s → L = 200 * 0.02 = 4 concurrent requests

Option A (vertical): halve S to 0.002 s → ρ = 0.4, W ≈ 0.002/0.6 = 0.0033 s → much lower latency.

Option B (horizontal): add 2 identical instances (3 total) → per-instance arrival ≈ 200/3 ≈ 67 req/s → ρ = 67 * 0.004 ≈ 0.268, W ≈ 0.004/0.732 ≈ 0.0055 s → overall system capacity ≈ 3 * (1/S) = 750 req/s max theoretical.

**Recommendation (systems perspective)** - If single-instance CPU/threads/lock contention are the limiter and vertical upgrade yields big S reduction, vertical is fastest. - If you need sustained capacity growth, stateless design, and downstream services scale, prefer horizontal for fault tolerance and capacity headroom. - Always validate with measurements: profile S components, test with load, and check downstream services before choosing.

Unlock Full Question Bank

Get access to hundreds of Architecture and Technical Trade Offs interview questions and detailed answers.

Join thousands of developers preparing for their dream job.