Business Requirements and Technical Alignment Questions

Focuses on the candidate ability to translate business requirements into technical architecture and product decisions. Expect discussion of how market timing, customer needs, competitive positioning, cost and resource constraints influence technical trade offs. Candidates should demonstrate how to balance ideal technical designs with pragmatic business driven solutions, how to prioritize engineering work based on impact, and how to communicate trade offs to technical and non technical stakeholders.

HardSystem Design

56 practiced

Design an architecture to provide high availability across regions for a system that stores personal data, but regulations prevent cross-border replication of PII. Provide options for disaster recovery, failover, and read locality while staying compliant and explain the trade-offs in latency and cost.

Sample Answer

Requirements & constraints (clarify first)- Global availability and low read latency- PII must remain within originating country/region (no cross-border replication)- Support DR, failover, read locality, compliance/audit- RPO/RTO targets, expected traffic patterns, and allowed legal exceptions

High-level pattern- Deploy a region-local “data sovereignty domain” in each jurisdiction that stores PII (Region-PII). Those domains are authoritative for local users.- Deploy globally replicated stateless services and non-PII stores (Global-Shard) for indexes, search tokens, analytics, and app logic.- Use a cross-region orchestration layer (control plane) that contains only metadata and opaque references (tokenized IDs), not PII.

Architecture options

1) Active-Active by region (recommended when low latency globally matters)- Each Region-PII is active for its residents. Global stateless services route requests to the resident region for any PII reads/writes.- Non-PII data and analytics are replicated globally (CDN, read replicas) for locality.- Failover: In-region primary → local standby replica (within same legal boundary, multi-AZ). If full-region loss, route affected users to a different region but: - Option A: Read-only degraded mode in other region using last-known tokenized snapshots (no PII) until lawful transfer/consent obtained. - Option B: Pre-arrange legal data transfer or emergency exception where allowed; otherwise rebuild from user-provided re-authentication.Trade-offs: Best read latency for locals, higher operational cost (per-region stateful clusters), complex routing and global consistency.

2) Active-Passive with cross-region backups (lower cost, simpler)- Primary Region-PII serves; other regions hold encrypted cold backups (snapshot snapshots stored but still cannot contain PII in other jurisdictions unless allowed). Backup storage kept within origin region; cross-region copies contain only encrypted blobs with keys held in origin KMS (so unreadable).- DR: Initiate failover by recovering backups to a standby cluster in same jurisdiction or, if allowed, perform key transfer/legal approval to decrypt in recovery region.Trade-offs: Cheaper, simpler, but higher RTO/RPO and potential legal workflow on failover.

3) Tokenization + Vaults + Proxy (best compliance flexibility)- Store PII in regional vaults (HSM/KMS + DB). Global services store only tokens/reference IDs. Any read of PII routes to token’s vault region via secure API call.- For read locality, implement edge caches of de-identified view or short-lived encrypted blobs (cache only when policy allows).- DR: Vaults replicate within same legal boundary (multi-AZ, same-country DR sites). Cross-region failover requires key escrow per legal policy.Trade-offs: Strong compliance, more network hops for PII reads so higher latency; cost for vault infrastructure.

Key implementation details & controls- Data plane separation: Strict network segmentation between PII stores and global services; enforce egress firewall rules and IAM that block cross-border PII replication.- Tokenization: Replace PII with opaque tokens in global systems; tokens map to local PII vault.- Encryption & key sovereignty: KMS per region; keys never exported except by legal process.- Auditing & consent: Full audit trail for access, data subject consent flags, and consent-aware routing.- Health & routing: Global API Gateway/Edge with geo-aware routing, circuit-breaker for region failures; fallback UX that explains degraded functionality when PII is inaccessible.- Backup & testing: Regular sovereign backups, automated DR runbooks, and cross-region DR drills under legal approval workflows.

Latency vs Cost trade-offs- Active-Active per-region: Lowest local latency, highest infrastructure and operational cost (duplicate DB clusters and compliance ops).- Tokenization+proxy: Moderate cost; PII reads incur extra hop to home region (tens to hundreds of ms depending on distance). Use regional caches for non-sensitive fields to reduce latency.- Active-Passive: Lowest cost but higher latency and RTO during failover; acceptable if outages are rare and business can tolerate delayed writes.

Recommendation (solutions-architect view)- For enterprise SLAs requiring low latency and minimal user disruption: implement Active-Active per-region with tokenization + regional vaults; global stateless layer serves UI and non-PII reads. Accept higher cost for compliance and performance.- For cost-sensitive customers with looser RTO: Active-Passive with strong sovereign backups and a legal-approved DR policy.

Include operational playbooks: region failure detection, user routing rules, communications, legal escrow process. Quantify choices for the customer (expected ms penalty per cross-region PII fetch, estimated 2–5× infra cost multiplier for multi-region stateful vs single-region).

HardTechnical

55 practiced

Compare building a proprietary real-time telemetry protocol versus adopting established protocols like gRPC or MQTT for a product differentiator. Consider performance, ease of client adoption, interoperability, maintenance, and total cost of ownership. Recommend an approach for a startup wanting low-latency telemetry with broad device support.

Sample Answer

High-level framing: building a proprietary real‑time telemetry protocol can maximize tailor-made performance and features, but established protocols (gRPC, MQTT) offer proven interoperability, tooling, and lower risk. For a startup requiring low-latency telemetry with broad device support, weigh trade-offs across performance, adoption, interoperability, maintenance, and TCO.

Comparison by criterion:- Performance: Proprietary protocol can be optimized (binary framing, custom ACKs, minimal headers, UDP/QUIC use) to shave microseconds and reduce jitter. gRPC (HTTP/2 or HTTP/3) gives excellent throughput and bidirectional streams with good latency; MQTT over TCP is lightweight but adds broker hops that can increase latency. Real gains from proprietary work mostly appear at extreme scale or very constrained networks.- Ease of client adoption: gRPC/MQTT have official libs across platforms, documented semantics, and community examples—vastly faster onboarding. Proprietary needs SDKs/SDK maintenance per platform; uptake is slower.- Interoperability: Standards win. MQTT/gRPC interoperate with cloud brokers, monitoring tools, and gateways. Proprietary locks you in or forces gateways/adapters.- Maintenance & Security: Standards receive security updates and ecosystem tooling (auth, certs, observability). Proprietary requires dedicated security lifecycle and more engineering headcount.- Total Cost of Ownership: Initial R&D and long-term maintenance for proprietary is high. Standards reduce time-to-market and support costs but may incur broker/managed service fees.

Recommendation (startup): Start with an established protocol—use gRPC over HTTP/2 or HTTP/3 (QUIC) for low-latency, bi‑directional telemetry where strong typing, streaming, and backpressure matter; use MQTT where extreme resource-constrained devices and intermittent connectivity dominate. If you need microsecond-level latency or special network behavior, implement a small, well-documented extension layer or a lightweight UDP/QUIC protocol as an optional high-performance path while keeping gRPC/MQTT as the primary interoperable option. Also provide SDKs, protocol-translation gateways, and benchmarks to justify performance claims.

Rationale: This hybrid minimizes time-to-market and TCO while preserving a path to optimize performance where justified. It aligns with sales/architecture needs: demonstrable device coverage, easy integration, and an upgrade strategy for future differentiation.

EasyTechnical

55 practiced

You're collaborating with a Product Manager who asks you to prioritize five engineering tasks given limited team capacity. Briefly explain how you would apply a prioritization framework (e.g., RICE or MoSCoW) to arrive at a ranked list and which dimensions you would emphasize for a revenue-driving feature.

Sample Answer

I’d use RICE because it’s quantitative and maps well to sales-driven outcomes; MoSCoW is a good complement for stakeholder alignment if we need simpler categories.

Step 1 — clarify tasks and constraints- Confirm the five tasks, expected effort in engineer-weeks, dependencies, and the target metric (e.g., ARR, conversion rate, deal close time).- Align with PM/sales on time horizon for revenue impact (next quarter vs. long-term).

Step 2 — apply RICE (Reach, Impact, Confidence, Effort)- Reach: estimate how many customers or deals this will affect in the time window (e.g., # of target accounts, % of leads).- Impact: relative effect on the revenue metric if implemented (e.g., 3 = big lift, 1 = small).- Confidence: probability that estimates are correct (0–100%) — penalize unproven solutions.- Effort: engineering-person-weeks.

Compute RICE score = (Reach * Impact * Confidence) / Effort. Rank by score.

Example (illustrative):- Task A: Payment gateway optimization — Reach 1000, Impact 2, Conf 80%, Effort 4 → RICE = (1000*2*0.8)/4 = 400- Task B: Enterprise SSO integration — Reach 200, Impact 3, Conf 90%, Effort 6 → RICE = 90- Task C: UI polish (checkout) — Reach 300, Impact 1.5, Conf 70%, Effort 2 → RICE = 157.5- Task D: Analytics events for funnel — Reach 1000, Impact 0.8, Conf 60%, Effort 1 → RICE = 480- Task E: Refactor core service (tech debt) — Reach 100, Impact 1, Conf 70%, Effort 8 → RICE = 8.75Rank: D, A, C, B, E.

Dimensions I’d emphasize for a revenue-driving feature- Time-to-revenue: short wins that unblock deals matter more.- Customer impact & reach: affects high-value accounts or conversion points.- Confidence/risk: prefer higher-confidence items when revenue sensitivity is high.- Dependencies / sales commitments: tasks promised to closed-won deals get higher priority.- Compliance/security if blocking revenue (e.g., data residency).

Finally, validate the ranking with PM and sales, surface any constraints (legal, integration windows), and iterate; document the rationale so stakeholders can revisit trade-offs when new info arrives.

MediumTechnical

84 practiced

A product team recommends self-managing a distributed database cluster instead of using a managed service to save costs for a projected 1M MAU SaaS product. Compare operational costs, resilience, feature differences, and migration complexity. Provide a recommendation with key assumptions for a SaaS vendor with moderate DevOps maturity.

Sample Answer

Situation/context: The product team is weighing self-managing a distributed DB cluster vs using a managed service for a projected 1M MAU SaaS product. As a Solutions Architect I’d compare four dimensions and give a recommendation with explicit assumptions.

Operational costs- Self-manage: higher ongoing staff costs (SRE/DBA time for ops, upgrades, security, capacity planning, backups, monitoring). Expect 1–2 FTEs at launch rising with scale; tooling, runbooks, and cloud infra egress/I/O costs add up. Hidden costs: incident toil, patch windows, and training.- Managed service: higher unit price (per-GB, IOPS), but much lower people cost and predictable billing. Faster time-to-market and lower TCO for moderate DevOps maturity.

Resilience- Self-manage: you control replication, failover, and backup strategy but must implement and test DR, multi-AZ recovery, and compaction/repair processes—higher risk without mature SRE practices.- Managed: built-in automated failover, backups, SLA-backed uptime, and cross-AZ/region replication options. Better RTO/RPO out of the box.

Feature differences- Self-manage: full control over versions, plugins, custom configs, advanced tuning and nonstandard extensions.- Managed: limitations on low-level access, but often offers advanced features (autoscaling, automated backups, point-in-time restore, monitoring integrations, encryption-at-rest) and faster security patching.

Migration complexity- Self-manage: if starting greenfield, complexity is in building mature ops; migrating later requires data export/streaming and downtime planning. For lift-and-shift from managed -> self-manage: schema, topology, and operational differences increase risk.- Managed: easier onboarding, often provides migration tools (CDC, import), simpler ops during growth.

Recommendation (for a SaaS vendor with moderate DevOps maturity)- Choose a managed database service initially. Rationale: at 1M MAU the priority is predictable availability, security, and minimal operational risk. Managed reduces headcount risk and accelerates product focus. Monitor cost per active user and performance for 6–12 months; if costs materially exceed thresholds and you have >3–4 experienced SRE/DBAs and strict needs (custom extensions, licensing optimization), plan a staged migration to self-manage with a parallel environment, extensive testing, and rollback plans.

Key assumptions- Traffic profile: read-heavy with predictable spikes; dataset fits common managed tiers.- Moderate DevOps maturity: team has cloud experience but limited running of complex distributed DBs in production.- Compliance: managed service meets regulatory needs or can be augmented (VPC, encryption, logging).- Cost target: managed cost must be within acceptable CAC/LTV economics; otherwise revisit.

EasyTechnical

69 practiced

Distinguish between functional and non-functional requirements (NFRs) with examples relevant to a regulated enterprise customer (e.g., an online health service). For three NFRs (security, latency, auditability), describe how you would translate each into measurable technical requirements and acceptance criteria.

Sample Answer

Functional requirements specify what the system must do (features, behaviors); non-functional requirements (NFRs) specify how the system performs those functions (quality attributes, constraints). For an online health service:

- Functional example: Patients can book telehealth appointments, upload lab results, view prescriptions.- NFR example: Data must be protected per HIPAA, service must respond quickly, and all accesses must be auditable.

For each NFR below I translate to measurable technical requirements and acceptance criteria:

1) Security (confidentiality, integrity, access control)- Technical requirements: - TLS 1.2+ for all transport; data-at-rest encryption AES-256. - Role-based access control (RBAC) with least privilege; MFA for clinicians and admin users. - Regular vulnerability scans and monthly patching window.- Acceptance criteria: - 100% of production endpoints use TLS 1.2+ (verified by automated scans). - Data-at-rest encryption verified for databases and backups. - Pen-test findings ≥ medium remediated within 30 days; no critical open findings.

2) Latency (performance)- Technical requirements: - 95th percentile API response time < 300 ms for core patient flows (login, record fetch). - CDN for static assets; auto-scaling backend to maintain SLO under defined load. - End-to-end page load (clinical dashboard) < 2s under typical load.- Acceptance criteria: - Monitoring shows P95 API latency <300 ms for 30 consecutive days in staging under production-like load. - Load test at 2x expected peak shows throughput without >1% error rate and latency within SLO.

3) Auditability / Traceability (compliance)- Technical requirements: - Immutable, tamper-evident audit logs capturing user-id, action, timestamp, source IP, resource affected. - Retention policy: logs retained for 7 years and searchable; logs exported to WORM storage and SIEM. - Correlation IDs for all requests for distributed tracing.- Acceptance criteria: - Sample audit shows required fields present for 100% of events over a 30-day window. - Log retention and WORM enforcement validated by storage policy test. - Given a simulated incident, traced request path recovered end-to-end within 1 hour.

These translations make NFRs testable, measurable, and actionable for design, acceptance testing, and compliance reviews.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.