Technical Requirements and Specifications Questions

Covers the end to end practice of translating product vision and business goals into clear, actionable technical requirements and specifications that engineering teams can implement. Includes writing product requirement documents and technical specifications with problem statements, success metrics, user and developer personas, API contracts and interfaces, data and schema considerations, functional requirements, and non functional requirements such as performance targets, latency and throughput expectations, scalability goals, reliability targets and service level objectives, security and privacy constraints, backward compatibility, and rollout and migration strategies. Encompasses requirements gathering techniques such as stakeholder identification, discovery conversations, clarifying questions, scoping, constraint identification for budget and timeline, defining measurable acceptance criteria, traceability to business objectives, and documenting assumptions and open questions. Also covers communicating requirements effectively to engineering and cross functional partners, knowing how to be specific without over constraining implementation, iterating requirements as learning emerges, and involving engineers early so they provide technical input and ownership.

EasyTechnical

43 practiced

Describe when and how engineers should be involved during PRD creation. Provide a short checklist an engineer can use to review a PRD for technical feasibility, missing constraints, testability, expected load, data needs, and rollout risk prior to implementation.

HardTechnical

29 practiced

Write a comprehensive requirements section to support GDPR right-to-be-forgotten for all user data produced by the system. Cover data discovery across services and third parties, deletion APIs, deletion in caches/backups/analytics, auditability and verification, testing and SLOs for deletion requests, and procedures for legal holds and exceptions.

Sample Answer

Requirements: GDPR Right-to-Be-Forgotten (RTBF) — System-wide deletion

Scope- Applies to all personal data (identifiers, profiles, activity, content, metadata, derived data) stored, processed, or transmitted by services, third-party processors, analytics, caches, backups, logs, and ML models.- Exemptions: data under valid legal hold or where retention is mandatory (documented per Legal).

Data Discovery & Inventory- Maintain up-to-date data map/catalog keyed by subject identifier(s) (user_id, email, device id) that lists: data type, storage location, retention policy, owner service, third-party recipients, and access patterns.- Automated discovery agents run weekly across databases, object stores, search indices, message queues, analytics pipelines, and config repos to detect new personal-data sinks; flag for owner onboarding.

Deletion API & Workflow- Provide a secure, authenticated DeleteSubject API (idempotent, audit-logged) accepting one or more identifiers and scope flags (soft-delete/erase, cascade).- Deletion request lifecycle: Received → Validate identity/consent → Pre-check legal holds → Start deletion job → Confirm deletion in all sinks → Mark completed with timestamp.- Support bulk and delegated deletions (admin/operator with elevated privileges) with approval workflow.

Deletion Semantics- Soft-delete marker where immediate physical purge is infeasible; enforce logical exclusion from product flows and analytics until physical purge.- Physical erase: overwrite and remove personal data from primary stores, indices, caches, ML training sets (see below), and third-party processors via contractual API calls.

Caches, Queues, Backups, Analytics, ML Models- Caches/edge: implement synchronous invalidation on deletion requests; max TTL for cached PII = 1 hour.- Message queues: support message redaction or dead-lettering; consumer contracts to ignore redacted messages.- Backups: tag backups with retention metadata; on deletion, flag backups for secure purge at next eligible window; for immutable retention windows beyond legal allowance, record legal hold or documented exception.- Analytics/aggregates: remove or re-aggregate to exclude subject; maintain derivation mapping to trace which aggregates include subject data.- ML models: track provenance of training data and provide retraining or selective unlearning. For models where retraining is impractical, document risk and mitigation, and consider model replacement for high-risk PII.

Third Parties- Maintain data-sharing registry and enforce Data Processing Agreements (DPAs) that require: - Immediate acknowledgement of deletion requests and completion within contractual SLA. - APIs or interfaces for remote deletion and attestations.- System must automatically notify third parties on deletion; retries and escalation if non-compliant.

Auditability & Verification- Immutable audit log for every deletion request: requestor, identifiers, scope, timestamps, affected locations, operator actions, third-party attestations, and final status.- Provide verifiable deletion report to user: what was deleted, when, and what remains (with legal justification).- Implement periodic (quarterly) audits and automated verification jobs that sample deletion records and re-scan stores to detect residual PII.

Testing & SLOs- Functional tests: unit/integration tests for deletion APIs, end-to-end deletion flows, and cache/backups handling.- Chaos tests: simulate partial failures, network partitions, third-party unavailability, and ensure idempotent retries and eventual consistency.- SLOs: acknowledge deletion request within 24 hours; complete deletion from primary stores within 72 hours; complete deletion from caches/edge within 1 hour; third-party completion per DPA (max 30 days). Track SLA compliance metrics and alert on degradation.

Legal Holds & Exceptions- Legal hold API to place or release holds; holds override deletion until lifted and are recorded in audit logs with case reference.- Exception workflow: automated deny with user-facing explanation when hold exists; support manual review for contested cases with approval audit trail.

Operational Controls & Security- RBAC for delete actions; multi-person approval for bulk deletions; rate limits and fraud detection to prevent abuse.- Encrypt data at rest and in transit; secure deletion where possible (overwrite/crypto-shred).

Deliverables- Data catalog, DeleteSubject API spec, third-party DPA templates, audit-reporting UI and endpoints, test suites, runbooks for incidents, and quarterly compliance reports.

Metrics- % deletions completed within SLOs, audit discrepancy rate, third-party compliance rate, number of legal holds, and mean time to resolve deletion failures.

HardTechnical

31 practiced

Write a technical specification for rotating encryption keys used to encrypt user data at rest without downtime. Include KMS integration, envelope encryption details, rolling re-encryption strategy, key metadata management, rollback and fallback handling, audit trails, and testing plans to ensure no data loss and continued compatibility with older keys during rotation.

Sample Answer

Scope and goals:- Rotate Key Encryption Keys (KEKs) used to wrap Data Encryption Keys (DEKs) for user data at rest with zero downtime, preserving the ability to decrypt with older KEKs until re-encryption completes. Provide auditable, reversible, and tested procedures integrated with KMS.

Architecture overview:- Envelope encryption per object: each object encrypted with a unique DEK (AES-256-GCM). DEK is wrapped (encrypted) by a KMS CMK (KEK) using an authenticated wrap (KMS Encrypt or Encrypt+AEAD). Store ciphertext and wrapped_key metadata with object.- KMS: use managed KMS (or HSM-backed) for CMKs. Use key versions/aliases (e.g., projects/key-name/versions/v1). Ensure CMK IAM/policy restricts access and enables audit logging.

Key and metadata model:- Object metadata fields: - wrapped_key: base64 ciphertext of DEK - kek_id: KMS key resource id (alias) and version used to wrap - dek_algorithm: "AES-256-GCM" - dek_iv / aad_hash (if applicable) - wrap_algorithm: e.g., "KMS-AES-GCM-v1" - rewrap_state: enum {current, pending, rewrapped_v2, failed_attempts} - last_rewrap_at, rewrap_attempts- Central Key Registry: maps key alias → active version, rotation schedule, policy, and archive of previous versions.

KMS Integration:- Use KMS Encrypt/Decrypt or Asymmetric wrappers as supported, call via authenticated service account.- Use deterministic key version identifiers in metadata. Never rely solely on "alias" without version when storing historical wrapped keys.- Configure audit logging to capture Encrypt/Decrypt/GenerateDataKey events with requestor identity, key version, request time, and operation result.

Rotation strategy (rolling, zero-downtime):1. Create new key version in KMS (vN+1). Set as "active" for new encrypts via central registry (atomic config flip—feature flag or config store with versioned updates).2. New writes: - Generate DEK per-object with secure RNG. - Encrypt object with DEK. - Call KMS Encrypt with active KEK version to wrap DEK; store wrapped_key + kek_id version.3. Re-encryption background worker: - Pick subset (shards) of objects to rewrap. Use work queue with idempotent tasks. - For each object: a. Read metadata; call KMS Decrypt with wrapped_key & kek_id to obtain DEK. If Decrypt fails due to key archival, fallback flows (see below). b. Option A (preferred): call KMS ReEncrypt (if KMS supports rewrap) from old KEK version → new KEK version (atomic server-side rewrap). Update metadata with new wrapped_key & new kek_id in single DB transaction. c. Option B: locally decrypt using DEK, then call KMS Encrypt using new KEK to produce new wrapped_key, update metadata. - Update rewrap_state atomically (DB transaction or compare-and-swap on object metadata) to avoid races. - Throttle workers: limit rewrap TPS by load and IOPS; use backoff for KMS rate-limit errors.4. Verification: after update, run integrity check (try decrypting DEK with new KEK or attempt decrypt of object using DEK). Mark success.

Rollback & fallback handling:- Never delete old KEK versions immediately. Keep previous KEK versions available until all objects wrapped by them are rewrapped and verified.- If a rewrap batch fails: - Log detailed error, increment rewrap_attempts. - If transient, retry with exponential backoff. - If systemic (KMS outage or key disabled), pause rewrap process via control flag, alert ops, and continue serving reads/writes using existing wrapped_key entries.- If new KEK is compromised, rotate to new emergency KEK and stop using compromised key; re-encrypt only after new secure KEK available. Maintain the ability to decrypt with archived old KEKs for rollback.- Ensure read path attempts decryption with kek_id from metadata; do not assume active key alias. Read logic: - Use kek_id version in metadata to call KMS Decrypt; if that fails due to key disabled, call fallback: check key registry for archived keys or use backup KMS account.

Audit trails & monitoring:- Audit entries for every key operation: create key version, set active, encrypt/decrypt/rewrap, rewrap worker events. Include object id, user/service identity, key version, timestamp, outcome.- Metrics: rewrap rate, backlog, failed rewraps, KMS errors, decrypt latency, per-key usage.- Alerts: high failed_rewrap_rate, stalled backlog, sudden spike in decrypt errors for a version, KMS permission changes.

Testing & validation plan:- Unit tests for wrapper/metadata handling, idempotency, and edge conditions.- Integration tests with KMS sandbox: Encrypt/Decrypt/rewrap flows, KMS error injection, rate-limits.- Canary rewrap: run rewrap on small percentage of objects; verify decrypt, performance, and correct metadata updates.- Chaos tests: simulate KMS outages, revoked key versions, partial transaction failures, and verify system continues serving reads/writes and rewraps resume correctly.- End-to-end: create dataset with mixed kek_versions, run full rolling rewrap to new version; verify all objects decryptable, checksums match, rewrap_state cleared.- Backup/restore: validate ability to restore objects and wrapped_keys and still decrypt after rehydration.- Security review: key policy, IAM least privilege, and penetration testing.

Operational runbook:- Pre-rotation: create new key version, run canary on test tenant, enable metrics dashboards, set throttles.- Execute: flip active alias, monitor write success, start background rewrap workers with small batch size and gradually increase.- Abort: set control flag to pause workers; to rollback new-encrypt usage, flip active alias back and stop rewraps. Rewrap partial data remains decryptable because metadata holds legacy version.- Post-rotation: when backlog=0 and verified, schedule archival of very-old KEK versions after a conservative retention window aligned with compliance; ensure archival policy preserves ability to recover if needed.

Security & compliance:- Maintain key retention policies per regulatory requirements.- Ensure KMS audit logs are immutable and stored per compliance.- Rotate service account credentials that access KMS on a schedule.- Encrypt metadata stores (DB) and restrict access to metadata to minimize attack surface.

Edge cases and notes:- If KMS supports server-side ReEncrypt, prefer it to avoid DEK exposure and reduce network transfer.- Make rewrap operations idempotent: include task idempotency keys and use compare-and-swap to avoid duplicate rewraps.- Plan capacity for KMS API quotas; request increases before large rotations.- Ensure backward compatibility: read path always honors kek_id in metadata, not only current active alias.

This specification ensures continuous availability, auditable key lifecycle, safe rollback, and thorough testing to avoid data loss while rotating keys.

HardSystem Design

29 practiced

Define an organization-wide API versioning and deprecation policy for 50+ microservices. Include rules for semantic versioning, backward-compatibility guarantees, discovery via a service catalog, automated compatibility checks in CI, deprecation windows, migration guides, client telemetry to track usage, and a suggested governance model.

Sample Answer

Requirements & goals:- Safe evolution of 50+ microservices with clear guarantees to clients.- Minimize breaking changes, provide discoverability, automate checks, and enforce deprecation & migration paths.- Low friction for engineers; measurable usage-based retirement.

Semantic versioning rules:- Use SemVer (MAJOR.MINOR.PATCH) for public API surface (HTTP/GRPC/SDKs). - PATCH: bug fixes, no behavioral/API changes. - MINOR: backward-compatible additions (new endpoints, optional fields, new enum values if clients ignore unknown). - MAJOR: any breaking change (renames, removal, behavioral changes).- Service-internal builds may use internal build numbers; only the published API version follows SemVer.

Backward-compatibility guarantees:- Clients pinned to X.Y.* guarantee: PATCH safe. Upgrading to X.(Y+N) should be safe for additive, opt-in features.- MAJOR bump explicitly indicates breaking changes; old major remains supported per deprecation window.

Discovery / service catalog:- Central service catalog (e.g., Consul/Service Registry + API Catalog UI) with: - Registered services, latest API version(s), published OpenAPI/Protobuf, change logs, migration guides, deprecation dates. - Machine-readable endpoint: /catalog/{service}/versions and schemas.

Automated compatibility checks in CI:- Enforce in each service pipeline: - Generate OpenAPI/Proto artifacts per commit and publish to a versioned artifact registry. - Run automated contract checks against previous published version(s) using tools: Swagger-diff, OpenAPI-diff, Buf (for protobuf) to detect breaking changes. - Block merges that introduce implicit breaking changes unless a MAJOR bump is present and approved. - Run consumer-driven contract tests (Pact or schema-based) where high-risk clients exist.

Deprecation windows & policy:- Standard windows: - Minor deprecations (optional fields): 90 days notice. - Endpoint removal or MAJOR breaking change: minimum 6 months notice. - Critical business-critical APIs extend to 12 months as agreed with stakeholders.- Deprecation announcement: catalog update, email/Slack to consumers, and in-response HTTP header (Deprecation: true; sunset: <date>).

Migration guides & tooling:- For each API change requiring client work, publish a migration guide in the catalog with: - Example requests/responses (before/after) - SDK upgrade instructions - Code snippets in primary languages (Java, Python, JS) - Automated compatibility shims where feasible (adapter layers).- Provide a "compatibility testing harness" CLI that consumers can run locally to test against new provider builds.

Client telemetry & usage tracking:- Enforce standard headers: X-Client-Id, X-Client-Version.- Central metrics pipeline (OpenTelemetry) to capture per-endpoint, per-client-version usage.- Dashboard in catalog showing active client versions and traffic percentiles; use this to time removals or accelerate deprecation.- If privacy/regulatory constraints apply, sample telemetry and aggregate by version.

Governance model:- API Governance Board: rotating 6–8 engineers + 1 PM + 1 infra owner. - Responsibilities: approve MAJOR bumps, decide exceptions, maintain policy, arbitrate disputes. - Weekly triage for proposed breaking changes.- Developer workflow: - Engineers propose change via API change RFC linking automated diff results and migration plan. - CI enforces rules; MAJOR changes require Board approval before merge.- Metrics & audits: - Quarterly report: number of breaking changes, average deprecation lead time, percentage of clients on latest minor/major.- Escalation & emergency changes: - Emergency MAJOR allowed with rollback plan, immediate communication, and temporary compatibility proxy if possible.

Trade-offs & practical notes:- Strict enforcement reduces regressions but may slow innovation—allow experimental, internal-only endpoints without SemVer constraints.- Invest in good automation (diffs, telemetry, docs) — upfront cost reduces long-term maintenance.

This policy provides clear rules, automated enforcement, consumer visibility, measured deprecation, and governance to keep 50+ services evolving safely.

MediumSystem Design

31 practiced

Write a technical requirements section for storing user activity events for analytics. Cover event schema design, ingestion pipeline choice (streaming vs batch), partitioning, retention, compaction, access controls, expected throughput and latency SLAs, and backfill strategies. Include acceptance criteria for end-to-end delivery latency.

Sample Answer

Requirements: store user activity events for analytics (product funnels, ML, BI).

Event schema design- Canonical event JSON: {event_id, user_id, event_type, event_time (ISO + epoch ms), platform, session_id, properties (map), device, geo, ingestion_metadata (producer_id, seq, sdk_version)}.- Schema registry (Avro/Protobuf) with versioning, backward/forward compatibility rules. Enforce required fields and types; properties is schemaless map for extensions.

Ingestion pipeline (streaming vs batch)- Primary: streaming (Kafka/PubSub) for near-real-time analytics and low-latency features (alerts, personalization).- Batch ETL from source lakes or historical loads for large backfills and heavy transformations (Spark/Flink).- Use stream processing (Flink/Beam) for enrichment, validation, deduplication, watermarking.

Partitioning- Topic/stream partition key: user_id hashed (uniform distribution); fallback event_time for time-range scans. Target partition count = expected throughput / 10k msgs/sec per partition (adjust by broker capability). Include partition key in schema metadata.

Retention & compaction- Raw events: retention 30 days (hot), cold storage to object store (Parquet) for 2+ years.- Compacted topic for latest per-user state (by user_id) with log compaction enabled to maintain latest user profile/update events.- Periodic batch compact/convert raw to partitioned parquet (time-partitioned by event_date).

Access controls- RBAC on topics/buckets: producers limited to ingestion cluster; consumers scoped per team. Use service principals and mTLS. Schema registry ACLs. Audit logging and per-field encryption for PII (tokenize user_id or store lookup in secure vault).

Expected throughput & latency SLAs- Throughput: steady 50k events/sec, peak 200k events/sec. Design headroom 2x.- Ingestion SLA: 99.9% of events accepted into stream within 5s of event_time.- End-to-end (stream -> analytics table) SLA: 95% delivered and queryable in 1 minute; 99.9% within 5 minutes.

Backfill strategies- Use batch job that reads source (object store or DB), validates, writes into Kafka topic with backfill flag; stream processors treat backfill flag to avoid double-processing. For large historical loads, write directly to partitioned Parquet and mark as available to analytics (skip streams).

Acceptance criteria for end-to-end delivery latency- Synthetic test: produce 10k events with timestamps now; 95% appear in analytics dataset (partitioned by event_date) and return valid query results within 1 minute; 99.9% within 5 minutes. Monitoring/alerts if SLA breached for >5 minutes.

Unlock Full Question Bank

Get access to hundreds of Technical Requirements and Specifications interview questions and detailed answers.

Join thousands of developers preparing for their dream job.