System Architecture Communication and Documentation Questions

Assess the candidate ability to describe, document, and communicate system architecture both visually and verbally. Candidates should present what a system does and who uses it, identify major components and how they interact, show data flow and integration points, and explain critical architectural decisions and trade offs. Interviewers expect clear diagrams using standard conventions that show high level views, component interactions, and deployment topology, accompanied by concise narrative documentation. Strong answers include multiple views tailored to the audience, labeled diagrams, and justification of design choices while avoiding unnecessary implementation detail. Candidates should be able to discuss scaling strategies, reliability and operational considerations including failure modes, migration paths, observability, and deployment considerations. The scope includes common architectural building blocks such as microservices, application programming interfaces, databases, caching layers, and message buses, as well as consistency and availability implications and service to service communication patterns, and the connection between technical choices and business context.

MediumTechnical

50 practiced

Document integration points with external systems such as tax calculation, identity verification, and analytics. For each integration, describe authentication, request/response formats, rate limits, error handling and fallback strategies. Provide a short sequence diagram for the flow when an external dependency fails and how your system degrades gracefully.

Sample Answer

Below is a concise integration-spec for three external systems (Tax Calculation, Identity Verification, Analytics) including auth, payloads, rate limits, error handling/fallbacks, plus an ASCII sequence diagram showing graceful degradation when an external dependency fails.

Tax Calculation (e.g., AvaTax):- Authentication: OAuth2 client_credentials → access token in Authorization: Bearer <token>. Token refresh 5min before expiry.- Request/Response: JSON over HTTPS. Request includes {orderId, items:[{sku,qty,price}], shippingAddress:{country,region,postalCode}, currency}. Response: {taxAmount, breakdown:[{jurisdiction,rate,amount}], transactionId, expiresAt}.- Rate Limits: 200 req/min. Implement token-bucket client-side with backoff.- Error Handling & Fallback: - 2xx: accept. - 429: exponential backoff + retry up to 3 times; if still 429, queue request and continue with cached tax rates. - 5xx / network: fall back to the most recent cached tax table (regional averages) and mark order as “tax-provisional” pending reconciliation. Alert ops if >5% of transactions use fallback.

Identity Verification (e.g., IDNow/Trulioo):- Authentication: Mutual TLS (mTLS) + API key in header X-API-Key. Enforce rotating keys monthly.- Request/Response: Multipart/form-data for images + JSON metadata: {userId, dob, documentType}. Response: {status: VERIFIED|PENDING|REJECTED, confidenceScore, providerReference}.- Rate Limits: 50 verifications/min.- Error Handling & Fallback: - 429: throttle at client; surface “verification delayed” UI state, allow limited feature access. - Rejection: surface reason to user, provide remediation steps. - Network/mTLS failures: retry 2 times quickly; if persistent, move to asynchronous verification queue and allow soft-limited access (e.g., spending cap) until verification completes. Log and create a support ticket if verification pending >24h.

Analytics (e.g., Segment/Amplitude):- Authentication: Write key in HTTPS header Authorization: ApiKey <key>. Use TLS 1.2+.- Request/Response: JSON batched events: [{userId, event, properties, timestamp}]; server responds 200 with accepted count or 207 partial success.- Rate Limits: 1000 events/sec or batch-size limit (e.g., 500 events).- Error Handling & Fallback: - 429: buffer events to local persistent queue (disk-backed), apply jittered retry. If queue > threshold (e.g., 10k events), drop oldest non-critical events. - 5xx: same buffering; if prolonged outage, enable reduced sampling (e.g., 10%) to conserve queue. - Local privacy filter applied before enqueue to avoid PII leakage.

Cross-cutting patterns:- Circuit Breaker per-integration (open after N failures within window); health-check background probe to half-open.- Idempotency keys for retry-safe operations (tax transactionId, verification requestId).- Observability: metrics for success/failure/latency, tracing headers propagated.- Security: encrypt queues at rest, redact PII in logs, rotate keys, monitor auth failures.

Sequence diagram (external failure causing graceful degradation):User -> App: Checkout (order)App -> TaxService: calculateTax(order) [call1]TaxService -> App: 503 / timeoutApp -> Cache: getCachedTax(order.region) => cached ratesApp -> OrderDB: createOrder(order, tax=cached, taxStatus=PROVISIONAL)App -> Analytics: track(event="order_created", properties={taxSource:"cached"})App -> Alerting: createIncident("Tax API failure")App -> User: show confirmation with message "Taxes provisional — final amount after verification"

Notes:- Orders created with provisional tax flagged for reconciliation when TaxService recovers: background job queries TaxService using stored idempotency keys and adjusts orders, emitting refund/charge events as needed.- All retries use exponential backoff with jitter; user-facing messages are actionable and avoid technical detail.

HardTechnical

57 practiced

How would you document SLOs and SLAs for a customer-facing API in an architecture guide? Include definitions of SLIs, SLO targets, error budget policies, escalation paths, and automated responses when error budget burn is detected. Provide an example SLO and the associated alert thresholds you would include in the docs.

Sample Answer

Start with concise definitions, then document measurable SLIs, concrete SLO targets, an error‑budget policy (including automated mitigations), clear escalation paths, and exact alert thresholds.

Definitions- SLI (Service Level Indicator): a measured signal of customer experience (e.g., request success rate, latency P95, throughput).- SLO (Service Level Objective): the target value for an SLI over a defined time window (e.g., 99.95% availability monthly).- SLA (Service Level Agreement): contractual commitments to customers tied to penalties/credits; derived from SLOs but usually more conservative and legally scoped.- Error budget: 1 − SLO (the allowable fraction of bad requests in the SLO window).

How to document SLIs- Success rate: percentage of API requests returning 2xx within business-logic success (exclude reject-by-design 4xx where appropriate). Measurement: rolling 28-day window, weighted by user impact.- Latency: P50, P95, P99 measured at edge after auth, include end-to-end processing only.- Availability: % of 1-minute buckets with success_rate ≥ 99% (explains bucketing to avoid flapping).

Example SLOs (to include in guide)- Availability SLO: 99.95% successful requests per 30-day window (error budget = 0.05% ≈ 21.6 minutes/month of unavailable time).- Latency SLO: P95 latency ≤ 200 ms over 7-day window.- Error rate SLO: total 5xx rate ≤ 0.1% over 7-day window.

Error budget policy- Define burn-rate = observed_error_rate / allowed_error_rate.- Tiers and responses: - Green (burn-rate ≤ 1): normal ops, prioritize features. - Yellow (1 < burn-rate ≤ 4 for 24h OR >25% of budget used in 24h): limit non-critical releases, pause low-risk experiments, increase monitoring frequency. - Red (burn-rate > 4 OR 100% budget consumed projected within 24h): freeze deploys, enable automated mitigations, invoke incident process.- Automated responses (documented playbooks): - Auto-scale or route traffic away from failing regions. - Throttle/queue non‑critical or bulk endpoints (e.g., background jobs, exports). - Feature flag rollback for recent deploys that increased errors. - Graceful degradation: switch to read-only, simplified payloads, or cached responses. - Auto-create incident in pager system and annotate burn-rate.

Escalation path (explicit)- Automated page to on-call SRE/engineer for critical (immediate high-severity).- If unresolved 30 min: escalate to service owner/engineering manager.- If unresolved 2 hours or SLA risk: product manager + customer success notified (predefined message templates).- Legal/exec level only when SLA breach confirmed or customer impact high; include communication owners and timeline.

Alert thresholds to include in docs- Immediate page: sustained 5xx rate > 1% for 3 minutes OR P95 latency > 500 ms for 5 minutes.- Warning (email/Slack): error budget burn > 25% used within 24 hours OR projected full spend within 72 hours.- Critical page: error budget projected to be exhausted within 24 hours OR burn-rate > 4 sustained for 30 minutes.- Post-deploy alert: new deploy increases 5xx rate by > 0.5 percentage points vs 30-min pre-deploy baseline → automatic rollback flag and page to deploy owner.

Measurement and provenance- State exact metrics sources (edge logs, API gateway, app metrics), aggregation windows, and how retries/client timeouts are handled.- Include SQL/PromQL examples and dashboards links for reproducibility.

Documentation checklist (what to include)- SLI definitions with SQL/PromQL snippets- SLO targets with time windows and error budgets- Burn-rate calculation and thresholds- Automated mitigations and runbooks- Escalation matrix and contact roles- Alert rules, channels, and sample messages- SLA mapping and customer notification templates

Rationale- Concrete, measurable SLIs avoid ambiguity. Bucketing and rolling windows reduce noise. Error-budget-driven controls balance innovation and reliability; automated mitigations reduce human latency and limit customer impact, while clear escalation keeps stakeholders aligned.

MediumSystem Design

54 practiced

When a system uses a message bus, what patterns and documentation items must you include? Cover pub/sub, work queues, event sourcing, ordering guarantees, durability, schema evolution, and consumer contracts. Provide a short example event contract and describe how you would version it in the docs.

Sample Answer

When designing a message-bus architecture include both patterns (how messages flow) and documentation (how teams consume/produce safely).

Patterns and what to document:- Pub/Sub (broadcast): document topic names, semantics (event vs command), retention, fan-out limits, and intended subscribers.- Work queues (competing consumers): document queue name, visibility timeout, retry/backoff, dead-letter policies, and idempotency requirements.- Event Sourcing: document aggregate boundaries, storage of events vs projections, snapshot policy, and rehydration instructions.- Ordering guarantees: specify per-topic partitioning key, whether ordering is per-partition or global, and implications for consumer scaling.- Durability: retention, replication factor, ack semantics (at-least-once, at-most-once, exactly-once), and backup/restore procedures.- Schema evolution: state explicit compatibility rules (backward/forward/full), allowed changes, tooling (Avro/Protobuf/JSON Schema), and migration playbooks.- Consumer contracts: publish “consumer contract” docs listing required fields, business invariants, error handling expectations, SLA (latency, throughput) and testing harness.

Example event contract (JSON Schema):

json

{
  "$id": "https://example.com/schemas/order.created.v1.json",
  "title": "OrderCreated",
  "type": "object",
  "properties": {
    "event_id": {"type":"string"},
    "occurred_at": {"type":"string","format":"date-time"},
    "order_id": {"type":"string"},
    "customer_id": {"type":"string"},
    "total_cents": {"type":"integer"}
  },
  "required": ["event_id","occurred_at","order_id","customer_id","total_cents"]
}

Versioning in docs:- Use semantic versioning in the schema filename and metadata (v1, v2).- For non-breaking additive changes (optional fields): publish as v1 and mark consumers resilient.- For breaking changes: publish v2, provide migration guide, dual-write strategy or translation bridge, deprecation timeline and automated compatibility tests.- Include examples, sample payloads, CI validation (contract tests), and a changelog entry for each schema change.

MediumTechnical

43 practiced

Your service experiences a sudden 10x traffic spike for a marketing event. Describe, in documentation terms, a scaling strategy that covers short-term mitigation and medium-term capacity improvements. Include autoscaling policies, caching, queue backpressure, throttling, pre-warming, and rollback considerations. Document trade-offs and risks.

Sample Answer

Overview:This document describes a two-phase scaling strategy for a sudden 10x traffic spike: (A) Immediate (minutes–hours): mitigation to maintain availability and avoid cascading failures; (B) Medium-term (hours–days): capacity and resiliency improvements to stabilize at higher baseline.

A. Short-term mitigation1. Rapid traffic shed & throttling- Apply per-API and global rate limits at edge (CDN/WAF/API gateway). Use token-bucket with conservative limits for anonymous clients and higher for authenticated.- Graceful 429 responses with Retry-After header and informational page for marketing users.Trade-off: reduces revenue/UX for some users but prevents outage.

2. Caching & CDN- Increase CDN TTLs for static and cacheable responses; enable surrogate keys for targeted invalidation.- Serve stale-while-revalidate for high-read endpoints.Risk: slightly stale data; acceptable for marketing content.

3. Queue backpressure & degrade noncritical work- Switch async pipelines to backpressure mode: pause workers consuming external services, increase queue retention, and persist incoming requests to durable store.- Defer or drop low-priority jobs (email digests, analytics).Risk: delayed downstream processing; requires consumer idempotency.

4. Autoscaling emergency rules- Trigger aggressive scale-out: lower CPU/RPS thresholds, increase max replicas temporarily (e.g., 3x normal cap).- Use health checks to avoid scaling on overloaded unhealthy instances.Risk: over-provisioning costs; cloud limits may block growth.

5. Pre-warming & reserve capacity- If scheduled event known, immediately spin up warm instances and pre-warm caches and connection pools.- Warm DB connection pools and external API clients.Trade-off: higher cost for idle capacity.

B. Medium-term capacity improvements1. Autoscaling policy tuning- Implement target-tracking scaling on request-based metrics (RPS per instance) and custom latency SLOs; add cooldown windows; use predictive scaling based on historical event patterns.- Horizontal scaling preferred; vertical only for stateful components with careful drain.

2. Caching & data layer- Introduce/migrate to read replicas and cache layers (Redis/Memcached) for hot keys; shard caches if necessary.- Cache computed views for heavy aggregation endpoints.

3. Queue architecture- Increase queue throughput: partition topics, add more consumers with idempotent processing, and implement backoff/retry strategies.- Implement circuit breaker pattern for downstream failures.

4. Rate-limiting strategy refinement- Implement client-level SLAs and tiered throttling; graceful degradation UI/UX and countdowns.

5. Capacity planning & autoscaling quotas- Request quota increases from cloud provider; run load tests to validate autoscaling behavior and cold-start characteristics.

Rollback considerations- All changes must be deployable behind feature flags and with automatic rollback on health degradation (e.g., sustained 5xx > X% or latency > SLO for Y minutes).- Maintain blue/green or canary deployments; keep runbooks for manual rollback and DNS/CDN cache invalidation steps.

Monitoring & Runbook- Dashboards: global RPS, p95/p99 latency, error rate, queue depth, CPU/memory, cache hit ratio.- Alerts: sustained error > threshold, queue depth growth, scaling failures, provider limits reached.- Runbook: sequence for throttling levels, cache TTL changes, emergency scale-out, and rollback steps.

Trade-offs & Risks- Cost vs availability: aggressive scaling and pre-warming increase spend.- Staleness vs performance: caching/serve-stale improves latency but may return outdated data.- Complexity vs reliability: adding queues, shards, and predictive scaling increases operational complexity.- Provider limits: cloud account quotas can block scaling—request increases proactively.

This plan prioritizes availability and graceful degradation immediately, then stabilizes capacity and lowers risk through tuned autoscaling, caching, and resilient queueing.

MediumTechnical

47 practiced

Describe service-to-service communication patterns (REST, gRPC, GraphQL, brokered messaging) and explain how you would document timeouts, retries, circuit-breakers, backpressure, and idempotency guarantees. Include a short diagram of a call graph showing synchronous and asynchronous paths.

Sample Answer

Service-to-service patterns- REST (HTTP/JSON): simple, human-readable, wide tool support. Best for request/response, intermediate latencies, cacheable GETs.- gRPC (HTTP/2, protobuf): low-latency, streaming support, strong typing, efficient binary wire — good for high-throughput RPCs.- GraphQL: client-driven queries, single endpoint that reduces over/under-fetching; use for rich client APIs but harder to cache and monitor.- Brokered messaging (Kafka, RabbitMQ): async, durable, great for decoupling, event-driven and buffering spikes.

How to document operational guarantees (practical template to include in service README / API spec):- Timeouts: specify client and server timeouts (e.g., client 2s, server handler 1.5s). State transport-level (HTTP idle vs request) and streaming keepalive.- Retries: policy table: max attempts, backoff strategy (exponential + jitter), idempotency requirement to allow retries, which status codes are retryable (e.g., 5xx, network errors), and circuit-breaker thresholds.- Circuit-breakers: thresholds (error rate 50% over 30s or 10 consecutive failures), open duration (60s), half-open probe behavior, metrics emitted (state transitions).- Backpressure: for streams and brokers, document max in-flight messages, consumer concurrency, high-water / low-water marks, and strategies (drop, buffer, throttle).- Idempotency: document idempotency keys, which endpoints are safe to retry without side effects, and how the server deduplicates (storage TTL for keys).

Example concise table entry:Service: PaymentService- Protocol: REST POST /payments- Timeout: client 3s / server 2.5s- Retries: 2 attempts, exponential backoff 200ms -> 800ms, only on network/5xx- Circuit-breaker: open if 5 failures in 30s, open for 60s- Idempotency: requires Idempotency-Key header; server stores key->response for 24h

Notes:- Synchronous paths (REST/gRPC) need strict timeouts/circuit-breakers to avoid cascading failures.- Asynchronous brokered paths provide buffering/backpressure but require careful consumer scaling and idempotency for at-least-once delivery.- Always include observability: metrics (latency, error rates, retries), distributed tracing, and dashboards for the policies above.

Unlock Full Question Bank

Get access to hundreds of System Architecture Communication and Documentation interview questions and detailed answers.

Join thousands of developers preparing for their dream job.