Ability to ask targeted questions to understand system requirements: user base, traffic volume (requests per second), latency targets, data consistency requirements, compliance/regulatory constraints. Understanding that different systems have different requirements and that constraints shape architecture decisions.
EasyTechnical
77 practiced
You are preparing to design a new customer-facing API for a large enterprise. What targeted clarifying questions would you ask stakeholders to understand user base size and segmentation, average and peak requests per second (RPS), latency SLOs/SLA, expected growth and seasonality, data consistency needs, third-party dependencies, and any compliance or regulatory constraints? For each question, briefly state why it matters for architecture decisions.
Sample Answer
**Situation & goal** I’m designing a customer-facing API for a large enterprise. Below are targeted stakeholder questions grouped by topic with a one-line rationale for architecture impact.**User base & segmentation**- How many active users and distinct clients today and by segment (internal apps, partners, public)? Why: drives auth, throttling, multi-tenant isolation, and capacity planning.- What percent of users are high-volume vs casual? Why: informs rate-limit tiers and caching strategies.**Traffic (average & peak RPS)**- What is current average RPS and peak RPS (5m/1m peaks)? Any SLAs tied to peaks? Why: capacity, autoscaling policies, load balancing, and cost estimates.- Can you share concurrency patterns (bursty, steady, long-polling)? Why: affects connection model (HTTP/2, websockets), pooling and limit settings.**Latency SLOs / SLA**- What are target SLOs (p50/p95/p99) and SLA penalties for violations? Why: dictates caching, regional placement, compute sizing, and retry/backoff design.- Are there per-endpoint latency targets (e.g., search vs bulk export)? Why: enables tiered architecture and CQRS for heavy operations.**Growth & seasonality**- Expected growth rate (monthly/annual) and known seasonal spikes (dates/multipliers)? Why: capacity planning, cost forecasting, and autoscale headroom.- Any marketing/feature launches that will change demand? Why: informs pre-warming and release-time runbooks.**Data consistency needs**- For each API, is strong consistency required or is eventual consistency acceptable? Provide examples. Why: choice between transactional DBs, caches with TTLs, read replicas, and design for idempotency.- Are there cross-region consistency requirements? Why: influences replication model and latency trade-offs.**Third-party dependencies**- Which external services will the API call, their SLOs, and retry semantics? Why: impacts circuit breakers, timeouts, and fallbacks to preserve SLA.- Any quotas or variable pricing from vendors? Why: affects throttling and cost controls.**Compliance & regulatory**- What compliance regimes apply (HIPAA, PCI-DSS, GDPR, SOC2)? Specific data residency or retention rules? Why: drives encryption, regional placement, audit logging, and data lifecycle policies.- Any required certifications or vendor constraints for cloud regions? Why: limits architecture choices and vendor selection.**Operational & security**- Who owns incident response, monitoring, and on-call? Which metrics matter? Why: informs observability, alerts, and runbook design.- Authentication/authorization patterns required (OAuth2, mTLS, API keys)? Why: influences API gateway, token lifetimes, and key rotation.These questions map directly to decisions on region placement, scaling models, data stores, consistency patterns, security controls, and operational runbooks.
MediumTechnical
101 practiced
Design an event-driven ingestion architecture for sensor telemetry requiring 50k events per second, ordering guarantees per device, and 99.99% delivery to analytics within 1 minute. What clarifying questions about ordering scope, idempotency, burst behavior, and retention would you ask, and what partitioning, buffering, and processing approach would you propose?
Sample Answer
**Clarifying questions**- Ordering scope: Is ordering required per device-id only, or per device + sensor-type + time-window? - Idempotency: Can downstream consumers handle deduplication, or must ingestion make events idempotent (e.g., dedupe keys)? - Burst behavior: Expected burst multiplier over 50k/s (x2, x10)? Any sustained peaks? - Retention & replay: How long must raw telemetry be retained for reprocessing (hours/days/weeks)? Is replay latency allowed?- Failure SLAs: Is the 99.99% delivery target end-to-end (ingestion → analytics) or ingestion → durable store?**Proposed architecture (high level)**- Ingress: API Gateway / MQTT / HTTP load-balanced fleet at edge (autoscaling), validating schema and stamping device-id + sequence/timestamp.- Partitioning: Use device-id as partition key into a partitioned message bus (Kafka/Kinesis/Event Hubs). Partition count sized for throughput: partitions >= peak parallelism; target ~1000 partitions for 50k/s (50 eps/partition average), tuned for bursts.- Ordering: Achieve per-device ordering by hashing device-id to a single partition. For device groups with hot keys, virtual sharding: append epoch shard (device-id + shard-id) managed by a device-to-shard map to split hot devices.- Buffering & durability: Short-lived durable log (Kafka retention short window e.g., 24–72h) plus cold raw storage (S3) for replay. Use producer acks and retries; persist to S3 asynchronously for end-to-end durability.- Processing: Consumer autoscaling per-partition with exactly-once or at-least-once semantics. Implement idempotent sinks in analytics (dedupe by event-id or sequence number) or use transactional writes (Kafka Streams/Flink with checkpoints).- Delivery SLOs: Stream processing with low-latency windowing and backpressure controls; set service-level monitoring for end-to-end latency and error rates to meet 99.99% within 1 minute.- Backpressure & bursts: Apply client-side rate limiting, token buckets, and tiered ingress (throttle low-priority devices). Use expanding buffer (Kafka) and spill to S3 when downstream falls behind.- Observability & ops: Metrics per-partition, consumer lag alerts, SLA dashboards, automated partition rebalancing playbooks, and chaos-tested failure scenarios.**Trade-offs**- Single partition per device guarantees ordering but risks hot partitions — mitigated by virtual sharding. - Exactly-once adds complexity; practical approach: at-least-once + idempotent sinks.
HardSystem Design
99 practiced
Design a rate-limited, multi-region webhook delivery system that guarantees at-least-once delivery with 99.99% success within 24 hours, supports per-customer throughput limits, exponential backoff, and duplicate suppression. What clarifying questions would you ask about consumer endpoint behavior, idempotency support, max concurrent connections per customer, and legal retry constraints? Propose an architecture including durable queues, retry scheduling, prioritization, and deduplication.
Sample Answer
**Clarifying questions (short list)**- Do consumer endpoints return standard HTTP status semantics (2xx = success, 4xx = client error, 5xx/timeouts = retriable)? Any custom codes?- Will consumers provide an idempotency key or can we require a deterministic event-id header? If not, how should we identify duplicates?- Per-customer limits: is the limit expressed as RPS, concurrent connections, or bandwidth? Are burst windows allowed?- Any legal/regulatory constraints on retry behavior (e.g., cease attempts after X failures, data residency, PII handling)?- Expected latency tolerance per delivery and allowed ordering guarantees (none / per-customer / strict)?**High-level SLA & requirements mapping**- At-least-once with 99.99% success in 24h → durable persistence + scheduled retries + DLQ + cross-region redundancy.- Per-customer throughput → per-customer rate limiter and concurrency controls.- Exponential backoff, duplicate suppression → scheduler + dedupe store + idempotency design.**Architecture (components & flow)**1. Ingress/API layer (global LB + auth) - Validate, attach event-id, persist to write-ahead store, ack producer.2. Durable regional queue - Kafka (geo-replicated) or cloud native queues (SQS + cross-region replication). Each event persisted to primary and replicated to secondary regions.3. Delivery orchestrator (per-region fleet) - Worker pool pulls events, consults per-customer Token Bucket limiter and concurrency semaphore. - Sends HTTP request with event-id and optional idempotency header.4. Retry scheduler - On transient failures, submit to a scheduled queue (time-wheel or priority queue) with exponential backoff (base, multiplier, max interval), jitter, and capped attempts. - Scheduler persisted (e.g., Redis streams + durable backing or DB) to survive restarts.5. Deduplication & idempotency - Persistent dedupe store: Redis + backing store (Cassandra/Postgres). Store mapping event-id -> delivery-state with TTL >= 24h (configurable). - Bloom filter for fast negative checks; persistent store for authoritative check. - Consumers encouraged to honor idempotency header; if not, server-side suppression: if event already delivered success -> drop retries.6. DLQ & operator workflows - After N attempts or exceeding 24h SLA without success, move to DLQ with visibility + alerting; provide web UI for manual retry.7. Observability & SLO enforcement - Metrics per-customer: success rate, latency, retries, throttled events. - Automated escalation when customer exceeds SLA; adaptive backpressure (slow consumers get lower priority).8. Multi-region resilience - Active-active regions with consistent hashing by customer to route delivery origin; failover pulls from replicated queues if a region is down.**Rate limiting & prioritization**- Per-customer Token Bucket for long-term rate, leaky-bucket for concurrency.- Priority tiers: emergency/system events > paid customers > free. Scheduler uses multi-level queues; when throttled, lower-priority events are delayed but persisted.- Enforce max concurrent connections per customer via semaphores per customer in orchestrator.**Deduplication semantics**- Event-id required; if absent, compute fingerprint (sha256 of payload + headers) and canonicalize.- Store: event-id -> {delivered: bool, last_attempt_ts, attempts}. On success set delivered=true; discard duplicates.- TTL retention >= SLA (e.g., 48h) to allow suppression beyond 24h retry window.**Trade-offs & rationale**- Kafka/georeplication ensures durability and high throughput; SQS simplifies ops but needs cross-region setup.- Redis+persistent backing balances speed and durability for dedupe; Bloom reduces cold reads.- Scheduler separation (workers vs scheduler) simplifies scaling and ensures retries survive restarts.**Edge cases & legal**- Provide per-customer policy to stop retries on explicit Do Not Contact flags.- For endpoints returning 4xx that indicate invalid webhook (410 Gone), move immediately to DLQ to avoid wasteful retries.This design meets at-least-once, supports per-customer throughput and concurrency, provides exponential backoff and duplicate suppression, and is resilient across regions while offering observability and operational controls.
HardSystem Design
89 practiced
Design an ingestion and processing pipeline for a global stock-exchange feed that requires sub-10ms in-region latency, ordering guarantees per symbol, and cross-region replication to backup sites for regulatory replay. What clarifying questions would you ask about message volume per symbol, symbol cardinality, burst behavior, and acceptable replication lag? Present an architecture addressing partitioning, ordering, backpressure, and failover.
Sample Answer
**Clarifying questions**- Peak and sustained messages/sec globally and per-symbol peak (e.g., top 1% symbols).- Total symbol cardinality (global and per-region).- Burst profile: micro-bursts (ms) vs sustained spikes (minutes); allowed drop or must buffer.- Max acceptable cross-region replication lag and RPO/RTO for backups.- Consumer model: push to matching engines, downstream analytics, or archival replay?- Security/PII/regulatory constraints and retention requirements.**High-level architecture**- Edge ingestion per region: TCP/TLS gateway + protocol parser (FIX/Protobuf). Gateways forward to regional broker cluster.- Broker: Partition by symbol using consistent hashing with virtual nodes; assign whole-symbol affinity to single partition to guarantee per-symbol ordering.- Use low-latency, in-region log system (e.g., dedicated Kafka Streams/Redpanda tuned with RDMA/pmem or a specialized in-memory log like Aeron/Chronicle Queue) for sub-10ms; collocate partitions on instances with kernel bypass.- Sequencing: per-partition sequencer ensures strict order; producers attach monotonic message sequence and broker validates.- Backpressure: token-bucket + credit-based flow control at gateway → reject/slow producers; in-broker per-partition in-memory ring buffers with configurable overflow to SSD persistence. Emit acks to producers.- Cross-region replication: async chained replication (leader in region streams to geo-replicator) with configurable max lag; use batching and parallel replication per-partition; for regulatory replay persist immutable segment store (S3/Archive) and shipping offsets.- Failover: partition leaders elect via quorum in-region; on region outage, elect global leader in backup site using multi-region consensus (raft with geo quorum) or controlled failover with preserved offsets; during failover, replay immutable log to restore ordering and resume with sequence checks.- Observability & testing: latency SLO dashboards, synthetic traffic per-symbol, chaos tests for failover and burst handling.**Trade-offs**- Synchronous cross-region replication increases latency; use async with tombstoned segments if strict zero-loss required.- Single-partition ordering limits parallelism per hot symbol—mitigate with symbol sharding (e.g., symbol+book) only if domain allows.
EasyTechnical
71 practiced
You are engaging with a regulated customer (for example, healthcare). What targeted clarifying questions do you ask to capture compliance requirements: data residency and locality, encryption-at-rest and in-transit, key management and who controls keys, audit logging needs, retention periods, breach notification timelines, and approved cloud regions/providers? Explain how each requirement affects architecture and vendor choices.
Sample Answer
**Targeted clarifying questions**- Data residency/locality: "Which countries, states or jurisdictions must data at rest and backups reside in? Are there dataflow restrictions (e.g., no cross-border transfers)?" Impact: choose cloud regions inside allowed jurisdictions, restrict multi-region replication, use provider region controls or on-premise/edge nodes.- Encryption at rest/in transit: "Are specific algorithms/standards required (AES-256, TLS1.2+)? Must all internal service-to-service traffic be encrypted?" Impact: require provider-managed encryption options, enforce mTLS, load balancer and service mesh configs.- Key management & control: "Do you require customer-managed keys (CMK) or HSM-backed keys? Who owns/rotates keys and where are keys stored?" Impact: prefer KMS with BYOK/Import key/HSM options (Cloud KMS, CloudHSM, Azure Key Vault Managed HSM); influences SaaS integrations and compliance posture.- Audit logging: "Which events must be logged (access, admin, data exports)? What log integrity, retention and tamper-evidence requirements exist?" Impact: enable immutable, centralized logging (Cloud Audit Logs, SIEM), WORM storage, cryptographic signing.- Retention periods: "What are minimum and maximum retention windows for different data classes?" Impact: lifecycle policies, cold storage tiers, cost projections, legal hold capability.- Breach notification timelines: "What SLAs/legal timelines for breach notification and required forensic data must we meet?" Impact: incident response playbooks, monitoring, retention of forensic logs, contractual SLAs with vendors.- Approved cloud regions/providers: "Are there pre-approved clouds/providers or prohibited vendors? Any certification requirements (HIPAA, SOC2, ISO27001)?" Impact: narrow vendor selection, require Business Associate Agreements, favor providers with needed certifications.Summary: capture exact jurisdictional and technical constraints, map each to architecture choices (regions, KMS, encryption, logging, retention/lifecycle, incident response) and use them as gating criteria in vendor evaluation and design decisions.
Unlock Full Question Bank
Get access to hundreds of Clarifying Scope and System Constraints interview questions and detailed answers.
