Requirements to Architecture Mapping Questions

Bridges business and customer requirements to concrete architectural or non functional specifications. Candidates should extract throughput, concurrency, availability, latency, durability, security, compliance and budget constraints from scenarios and translate them into measurable goals such as requests per second targets, latency SLOs, durability levels, retention and encryption requirements. The topic includes creating a requirements matrix that directly informs component choices, capacity planning, and trade off justification.

HardTechnical

51 practiced

You're asked to lead a cross-functional initiative to ensure product requirements are consistently mapped to architecture across teams. Define the process, artifacts (for example a requirements-matrix template and SLO catalogue), roles and owners, gating checks in CI/CD, and KPIs to measure success over 12 months. Include onboarding and exception handling.

Sample Answer

Situation: I was asked to lead a cross-functional initiative to ensure product requirements are consistently mapped to architecture across teams.

Process (phased, 12 months)- Month 0–1: Kickoff & align goals with PM, Engineering, SRE, Security, QA.- Month 2–4: Define artifacts, owners, and pilot two product teams.- Month 5–8: Roll out to all teams, integrate gating checks in CI/CD.- Month 9–12: Measure, iterate, and embed into onboarding.

Core artifacts- Requirements-to-Architecture Matrix (template): rows = requirement id, priority, functional spec, nonfunctional (latency, throughput, security, compliance), mapped components/services, responsible architect, trace links to tickets, test plans, SLOs.- SLO Catalogue: service, SLA/SLO, error budget policy, measurement metric, alert thresholds, runbook link, owner.- Architecture Decision Record (ADR) template: decision, trade-offs, alternatives, impact on requirements/SLOs.- Traceability Dashboard: visualization of coverage gaps and recent failures.

Roles & owners- Initiative Lead (me): coordination, roadmap, executive reporting.- Product PMs: ensure requirements complete and prioritized.- Team Architects/Tech Leads: map requirements → design, maintain ADRs.- SRE: define SLOs, instrumentation, CI/CD gating rules.- QA/Test Lead: automated tests & acceptance criteria.- Security/Compliance owner: approve nonfunctional requirements.- Program Manager: rollout schedule, training, metrics collection.

Gating checks in CI/CD- PR-level: validate requirement ID present, ADR link, SLO tags.- Build pipeline: run automated contract/unit/integration tests linked to requirement IDs.- Pre-deploy: SLO metric smoke tests, canary analysis, security scans.- Merge-blocker if required tests fail, or SLO measurement not present.

Onboarding & adoption- 2-hour interactive onboarding for new hires and existing teams, recorded playbook.- Pairing sessions: new teams pilot mapping with an architect.- Office hours and templates in internal wiki.- Incentivize via engineering review checklist and quarterly engineering excellence awards.

Exception handling- Exceptions logged via lightweight approval workflow: justification, mitigation, timebox, exec sponsor sign-off.- Temporary exceptions require compensating controls (monitoring, alerts) and expiry.

KPIs (12-month targets)- Coverage: 95% of features have requirement → architecture mapping within 2 sprints.- SLO adoption: 90% of services in SLO catalogue with active metrics.- Traceability gap reduction: 80% fewer unmapped requirements vs baseline.- Release stability: 30% reduction in post-release incidents tied to requirement mismatch.- Cycle impact: <5% merge-blocks due to missing requirement metadata after month 6.- Adoption: 100% of new hires complete onboarding within 2 weeks.

Why this works- Provides clear artifacts and owners so accountability is explicit, automates checks to catch regressions early, and measures both adoption and operational impact to iterate policies.

MediumSystem Design

50 practiced

Design a caching strategy for an API that must serve 200k RPS with p95 read latency <20ms while writes are 2k RPS. Specify cache levels (CDN, remote shared cache, in-process), TTL and acceptable staleness, invalidation mechanisms, cache warming, and how each map to the SLOs and operational concerns like cache stampede.

Sample Answer

Clarify constraints: 200k RPS read, p95 < 20ms; writes 2k RPS. Latency SLO drives multi-layer caching to serve most reads from in-memory layers while ensuring acceptable staleness for eventual consistency.

High-level layers1) CDN / Edge cache- Purpose: serve public/static or cacheable API responses (CDN POPs close to users) — offload traffic and reduce network hop.- TTL: 30s–60s for highly dynamic but cacheable resources; up to minutes for less-fresh data.- Staleness model: stale-while-revalidate 5–10s.- Invalidation: short TTL + cache-control + purge API for critical updates (used rarely).- SLO mapping: removes large fraction of global latency and traffic, reducing origin load and helping p95.

2) Remote shared cache (Redis cluster / clustered memcached)- Purpose: single source for cached API responses / DB-read results for application fleet.- Topology: sharded Redis Cluster with replicas; each shard in same AZs as app nodes; client-side hashing.- TTL: 5–30s depending on data criticality (e.g., 5s for balances, 30s for profile).- Staleness: acceptable 1–30s depending on key class; enforce stronger consistency where needed.- Invalidation: cache-aside writes: on write (2k RPS) update DB then publish “invalidate key/version” via Redis Pub/Sub or a reliable message bus (Kafka) to all app nodes and to CDN purge endpoints for critical keys. Use versioned keys (key:vNN) to allow fast invalidation by bumping version.- SLO mapping: Redis p95 < 1–3ms per op in-region; network + app processing should keep overall p95 under 20ms when hit.

3) In-process local cache (Caffeine / Guava / LRU)- Purpose: lowest latency, reduce Redis QPS for hottest keys.- TTL: very short (500ms–3s) with stale-while-revalidate up to a few seconds.- Staleness: small; critical paths use validation on miss.- Population: cache-aside reads populate local then remote; on invalidate receive pubsub to evict or bump local version.- SLO mapping: local hits return sub-ms to single-ms responses improving p95 significantly.

Cache patterns and invalidation- Primary pattern: cache-aside (read-through only when miss). For frequently read, low-write keys, consider write-through if immediate consistency required.- Versioned keys: embed version or use a metadata “generation” key; writes bump generation so clients ignore stale local entries without needing explicit purge.- Pub/Sub invalidation: on write, after DB commit, publish invalidation messages (key or version bump). App nodes listen and evict local caches and delete remote entries. Use reliable delivery (Kafka with compacted topic) for at-least-once semantics; include idempotency.- CDN purge: only for critical items; otherwise rely on short TTL + versioned URLs (e.g., include version token in CDN key).

Cache warming and cold-start- Warm hot keys at deploy or scale events using background pushers that read hot key list (from analytics of top N keys) and prefill Redis and optionally local caches.- On autoscale, use background fetch with rate limit to avoid overload; pre-shard warming across instances.- For large thumbnails/rare heavy items, generate asynchronously and cache.

Stampede and consistency protections- Request coalescing / singleflight: only one goroutine fetches DB/remote for a missing key; others wait up to timeout; prevents N concurrent DB hits.- Probabilistic early refresh: on access, if TTL remaining < threshold or sampled, trigger async refresh.- Mutex/lock fallback: use small distributed locks (Redlock) only for rare heavy recompute keys.- Graceful degradation: allow stale response if DB is down and TTL expired but cached stale available; attach served-from and staleness headers.- Rate-limit cache refreshes, circuit-break to DB on surge.

Operational considerations- Capacity: size Redis to handle target read miss rate; aim for >90% of reads served from local+Redis to meet p95. Monitor hit ratios and tail latencies.- Monitoring: per-layer metrics (hit/miss rates, latency p50/p95/p99), invalidation lag, pubsub backlog, eviction rates.- Alerting: rising miss ratio, Redis CPU, high pubsub lag, cache stampede signals (spike in DB QPS).- Failover: Redis replicas and read-only during failover; if Redis unavailable, fallback to local caches and DB with rate limiting.- Security: protect purge endpoints, auth for pubsub.

Example numbers (back-of-envelope)- Assume 200k RPS reads: if CDN handles 50% = 100k RPS, local cache handles another 40% = 40k RPS, Redis handles remaining 60k hits (misses to DB maybe 2–5k RPS). With Redis p95 ~1–3ms and local hits <1ms, and CDN <5ms, system can meet overall p95 <20ms.- With writes 2k RPS, invalidations are manageable; ensure pubsub can handle ~2k invalidations/sec.

Trade-offs- Short TTL reduces staleness but increases origin load; versioning + aggressive local caching balances freshness and load.- Strong consistency everywhere would require sync invalidation and higher write latency; instead choose per-key consistency levels.

This design meets p95 latency by prioritizing local and CDN hits, keeps writes decoupled with pubsub/versioned invalidation, prevents stampedes with singleflight and early refresh, and provides warming and operational controls to maintain SLOs.

HardSystem Design

57 practiced

Design a disaster recovery strategy for a payments platform requiring RPO <1 minute and RTO <5 minutes for core payment flows, multi-region failover, and regulatory auditability. Include backup/replication topology, DNS and traffic failover, data replay/reconciliation, testing cadence, and how each DR requirement maps to runbook checkpoints and measurable targets.

Sample Answer

Requirements & constraints:- RPO < 1 minute (data loss ≤ 60s), RTO < 5 minutes for core payment flows, multi-region failover, full regulatory audit trails (immutable logs, retention).

High-level architecture:- Active-primary region (A), active-standby region (B) with automated failover; a third region (C) for DR drills/archives.- Core components: API gateways, stateless payment processors, transaction coordinator (idempotent), persistent ledger DB, message queues, audit store.

Backup / replication topology:- Synchronous-ish replication for critical ledger: use semi-synchronous (group commit) DB cluster with WAL streaming to B; aim to commit in A and replicate WAL within <30s. Supplement with distributed consensus (RAFT/etcd) for coordination.- Asynchronous replicated object stores for blobs to B/C with cross-region replication.- Queue replication: mirror topics (e.g., Kafka MirrorMaker2 or Confluent Replicator) with consumer offsets replicated.- Immutable append-only audit logs (WORM) written to durable object store in all regions and copied to C for long-term retention.

DNS & traffic failover:- Global traffic managed by multi-cloud DNS (e.g., Route53 with health checks + latency routing) and Global Load Balancer (GCLB). Use health-monitoring + automated failover runbook to switch traffic to B within target.- To meet RTO <5m: pre-warm B (hot-standby) with autoscaling groups kept at minimal warm capacity; use session/cookie stickiness fallback and token replay.

Data replay & reconciliation:- Maintain monotonic transaction IDs and durable ordered WALs. On failover, apply any outstanding WAL entries from A to B (WAL catch-up) — must finish within RTO or allow façade that queues incoming requests and replays.- Reconciliation job: compare ledger hashes per time-window (e.g., 1-min buckets); any divergence triggers compensating transactions or manual review. Provide tools to reprocess idempotent events from mirrored queues.

Testing cadence:- Daily smoke tests of failover path (synthetic transactions) in isolated windows.- Weekly partial failover to B with controlled traffic shift (canary 5–20%).- Monthly full DR failover rehearsal to B including restore-from-snapshots to verify RPO/RTO.- Quarterly regulatory audit run: produce immutable logs, reconciliation reports, and runbooks.

Runbook checkpoints & measurable targets:- Pre-failover: health detection (<30s), alerting (<60s) — measured via SLOs.- Failover init: decision & runbook execution start <60s after alert.- Data sync catch-up: WAL replication lag <30s (measured), remaining events queued <X (target zero).- Service availability: API gateway routing switch complete <120s; core payment processing resumed <300s total.- Post-failover reconciliation: first hash comparison complete within 10 minutes; full reconciliation within 24 hours.- Auditability: immutable logs available in all regions within 60s of write; retention/compliance reports generated on demand.

Additional safeguards & trade-offs:- Hot-standby increases cost but required for RTO; synchronous replication can increase latency—use group commit tuned to <30s to balance.- Idempotency and compensating transactions simplify replay.- Maintain runbook automation (IaC scripts, one-click failover) with human approval gates for regulatory controls.

This design ensures RPO <1m via aggressive WAL replication and mirrored queues, and RTO <5m via pre-warmed hot-standby, automated DNS/LB failover, and clear runbook checkpoints with measurable SLOs for each phase.

EasyTechnical

61 practiced

Write a Python function required_instances(rps, avg_service_time_ms, concurrency_per_instance) that returns the minimum number of instances needed to meet requests-per-second given average service time in milliseconds and maximum concurrent requests an instance can handle. Assume uniform arrival distribution, no queueing, and ignore startup time. Include a short unit test for rps=1000, avg_service_time_ms=50, concurrency_per_instance=100 and explain the formula you used.

Sample Answer

To compute the minimum instances, note that each request occupies an instance for avg_service_time_ms/1000 seconds. Total concurrent requests needed at steady-state = rps * (avg_service_time_ms / 1000). Each instance can handle up to concurrency_per_instance concurrently, so required instances = ceil(total_concurrent_needed / concurrency_per_instance).

python

import math

def required_instances(rps, avg_service_time_ms, concurrency_per_instance):
    """
    Return minimum number of instances (int) needed to sustain rps given
    average service time in ms and max concurrent requests per instance.
    Formula:
      total_concurrent = rps * (avg_service_time_ms / 1000)
      instances = ceil(total_concurrent / concurrency_per_instance)
    Assumes uniform arrivals, no queuing, no startup time.
    """
    if rps < 0 or avg_service_time_ms < 0 or concurrency_per_instance <= 0:
        raise ValueError("rps and avg_service_time_ms must be >= 0; concurrency_per_instance must be > 0")
    total_concurrent = rps * (avg_service_time_ms / 1000.0)
    return max(0, math.ceil(total_concurrent / concurrency_per_instance))

# Short unit test
if __name__ == "__main__":
    # Given: rps=1000, avg_service_time_ms=50 -> total_concurrent = 1000 * 0.05 = 50
    # concurrency_per_instance = 100 -> instances = ceil(50 / 100) = 1
    assert required_instances(1000, 50, 100) == 1
    print("Test passed")

Key points:- Formula derives from Little's law style relation: L = λ * W (concurrent = arrival_rate * service_time).- Time/space complexity: O(1) time, O(1) space.- Edge cases: zero rps → 0 instances, very small service times may yield 0.<1 so ceil => 1 only if any positive concurrent needed; function guards invalid inputs.

HardSystem Design

63 practiced

You inherit a large microservice platform with inconsistent SLOs across services. Draft a twelve-month migration plan to standardize SLOs and alerting: top-down mapping from product journeys to service SLIs, templates and CI checks, tooling to collect SLIs, rollout phases (pilot, incremental adoption), remediation paths for services that fail SLOs, success KPIs and enforcement mechanisms.

Sample Answer

Requirements & constraints:- Standardize SLOs across ~N services mapping to business journeys (latency, availability, error-rate, throughput), low rollout risk, minimal runtime overhead, CI/automation, 12-month timeline.

High-level approach (top-down):1. Map product journeys → user transactions → dependent services. For each journey assign 1–2 primary SLIs (e.g., p95 end-to-end latency, successful request rate).2. Translate journey SLIs to per-service SLIs and target SLOs via dependency contribution models (error budget allocation).

12-month phased plan:Months 0–1: Kickoff & discovery- Inventory services, current SLIs/SLOs, owners.- Define SLO taxonomy, SLI definitions, error-budget policy, and SLA vs SLO rules.Months 2–3: Templates & tooling selection- Provide SLO/alert templates (YAML): SLI metric name, window, target, burn-rate alerts, remediation steps.- Choose stack: OpenTelemetry for instrumentation, Prometheus/Thanos for metrics, SLO tooling (Prometheus SLO exporter or Nobl9/SLOkit), Grafana for dashboards, Alertmanager for alerts.Months 4–6: Pilot- Select 3 representative services (user-facing, backend, batch).- Implement instrumentation, metrics collection, CI checks, dashboards; run 4-week pilot, tune SLIs/SLOs and alert thresholds.Months 7–9: Incremental adoption- Roll out to 30–50% services in waves by domain. Provide migration playbooks, office hours, and automated SDKs.Months 10–12: Organization-wide rollout & enforcement- All services onboarded, governance, review cadence, continuous improvements.

CI checks & templates:- Provide YAML SLO manifest + linter. CI job validates: - Presence of SLO manifest in repo - Metric names resolvable in Prometheus - Correct label use and alert rules generated- Example CI failure blocks merge and opens a remediation ticket.

Tooling to collect SLIs:- Libraries: OpenTelemetry SDK wrappers to expose standardized metric names/tags.- Collector config to route to Prometheus/Thanos.- SLO evaluation: Prometheus recording rules + SLO exporter or external SLO engine to compute burn rates and history.- Dashboards and alert rules autogenerated from SLO manifests.

Rollout & remediation:- Alerts: burn-rate (fast) and long-window (slow). On alert: - Pager duty → responder runs runbook. - If error budget exhausted: automatic mitigation path: reduce feature rollout (kill switch / feature flag), throttle traffic, rollback.- Quarterly SLO review for services missing targets — require remediation plan, paired engineering support, and follow-up checks. Repeat offenders: restrict deploy frequency, require extra code review and SLO gating.

Success KPIs & enforcement:- Adoption: % services with SLO manifest ≥ 95% by month 12.- Coverage: % user journeys with end-to-end SLOs = 100%.- Reliability: average error-budget burn across fleet ≤ threshold.- MTTR reduction for SLO incidents ≥ 30% after rollout.- Enforcement: CI merge-gates, release pipeline checks, quarterly audits, product/engineering OKR tie-ins.

Trade-offs & risks:- Measurement noise: invest in tagging standards and sampling.- Ops overhead: start with core SLIs, expand later.- Cultural: provide training, incentives, and support to get buy-in.

This plan balances product-aligned SLIs, automated enforcement via CI and tooling, staged rollout with pilot and remediation, and measurable KPIs to prove success.

Unlock Full Question Bank

Get access to hundreds of Requirements to Architecture Mapping interview questions and detailed answers.

Join thousands of developers preparing for their dream job.