Translating Business Problems to Computational Solutions Questions

Techniques for turning an ambiguous business request into concrete, buildable technical work. Covers eliciting requirements from stakeholders (including non-technical ones), distinguishing functional from non-functional requirements, defining measurable success criteria across business, product, and technical layers (e.g., SLAs/SLOs, KPIs, model-level metrics), scoping an MVP versus a full solution, writing user stories and acceptance criteria, and documenting open assumptions and trade-offs for the team that will build the solution. Applies whenever a high-level ask (an executive request, an RFP, a customer need) must be translated into a technical spec, architecture decision, or system requirement.

MediumTechnical

72 practiced

As a Solutions Architect, create a comparative TCO analysis outline for 'build custom search' vs 'use managed SaaS search'. List the cost categories, risk factors, and show an example table of one-year vs three-year costs and qualitative trade-offs you'd present to the customer.

Sample Answer

Framework/approach:- Clarify scope (documents, query volume, latency/SLAs, relevancy/custom ranking, languages, security/compliance, analytics, integrations).- Compare TCO across Build (custom search stack) vs Buy (managed SaaS search) for 1-year and 3-year horizons.- Capture quantitative costs + qualitative risks/trade-offs.

Cost categories (quantitative):- Initial project costs: design, PoC, integration, custom ranking/models- Licensing & software: open-source infra vs SaaS subscription- Infrastructure & hosting: servers, storage, network, CDN- Operational: DevOps, SRE, monitoring, backups- Development: feature work, ML relevance tuning, connectors- Support & maintenance: bug fixes, upgrades, security patches- Third-party: relevance tools, analytics, security audits- Opportunity cost: time-to-market, lost revenue from slower launches- Scalability costs: cost of scaling index/throughput for peak usage- Decommissioning / migration costs

Risk factors (qualitative):- Build: longer time-to-market, staffing risk, tech debt, security/compliance burden, scaling complexity, maintenance overhead- SaaS: vendor lock-in, per-query cost surprises, customization limits, data residency/compliance constraints, dependency on vendor SLAs

Example summary table (estimates, USD):

| Year 1 | 3-Year Total (Yr1+2+3)Build (custom) | $450k | $1.05M - Notes: infra $100k/yr, dev & ML tuning $250k Yr1, ops $100k/yr

SaaS (managed) | $275k | $675k - Notes: subscription $150k/yr, integration & config $75k Yr1, lower ops $50k/yr

Qualitative trade-offs:- Time-to-market: SaaS = fast (weeks), Build = slow (3–9 months)- Customization & control: Build = full control; SaaS = limited but often extensible via plugins/APIs- Cost predictability: SaaS = predictable subscription + per-use; Build = variable (staffing, scaling)- Scalability & reliability: SaaS = built-in autoscaling & SLA; Build = requires investment & expertise- Security/compliance: Build = full control (but operational burden); SaaS = may simplify compliance if vendor certified, but verify data residencyRecommendation pattern:- If speed, predictable ops, and moderate customization required → recommend SaaS.- If extreme customization, unique ML ranking, strict on-prem data residency and long-term cost amortization with in-house expertise → consider Build.Include sensitivity analysis (±30% query growth, 20% staffing variance) and next steps: validate assumptions with PoC, RFP to vendors, and detailed cost worksheet per customer-specific metrics.

HardSystem Design

74 practiced

You must integrate a mission-critical legacy ERP into a cloud-native microservices platform without downtime. Design a phased migration plan including data synchronization approaches, transaction integrity guarantees, reconciliation processes, and monitoring strategy for cutover readiness.

Sample Answer

Requirements & constraints:- Zero downtime migration; preserve transactional integrity for orders/finance; eventual consistency acceptable only if bounded and reconciled; no data loss; ability to rollback; phased cutover per bounded context; minimal change to legacy ERP initially.

High-level phased plan:Phase 0 — Assess & Instrument (2–4 weeks)- Inventory data/models, identify bounded contexts, critical transactions and SLAs.- Add change-data-capture (CDC) hooks (DB binlog/CDC tooling like Debezium) and read replicas; define canonical event schema.- Add observability on legacy (metrics, traces) and baseline performance.

Phase 1 — Read-only shadowing (4–8 weeks)- Stream CDC into a cloud event bus (Kafka) and materialize into microservice read models (CQRS). Microservices consume canonical events to build local state.- Implement idempotent event handlers and schema versioning.- Validate parity via automated reconciliation jobs (row-level checksums, counts, hashes) and business tests.

Phase 2 — Dual-read, single-write (6–10 weeks)- Route reads to new services where safe; writes continue to legacy ERP. Add read-through cache for consistency.- Implement an async write-proxy that records intended operations as events (event-sourcing facade). Events are queued and mirrored to legacy in-order.- Start implementing compensating actions for failures.

Phase 3 — Dual-write with transactional integrity (8–12 weeks)- Introduce dual-write through a transactional outbox pattern: microservices write to local DB + outbox atomically; an outbox dispatcher publishes events to legacy (API) and the event bus.- Use distributed saga orchestration for multi-service transactions; where strong consistency is required (financials), use a two-phase commit via the legacy adapter or serialized operation on a single authoritative service.- Continuously run reconciliation and automated discrepancy correction (idempotent compensating transactions).

Phase 4 — Switch writes & cutover (1–2 weeks controlled)- Feature-flaged traffic shift: route a small subset of writes to microservices authoritative path and compare results.- Gradually increase traffic while monitoring parity metrics; keep ability to divert back to legacy.- Final cutover when discrepancy rates are within threshold for X days.

Data synchronization approaches:- CDC (Debezium/Kinesis/Datastream) -> canonical events -> Kafka.- Outbox pattern for reliable publishing from microservices.- Transactional adapters for legacy APIs with retry, dead-lettering.- For large bulk historical data, use snapshot + incremental CDC window.

Transaction integrity guarantees:- Local transactions use ACID in microservices.- Cross-service consistency via Sagas (orchestrator or choreography) with stored compensation steps.- For critical ledger operations, route through an authoritative payment/ledger service that serializes operations; if legacy must remain source-of-truth, enforce a single writer pattern during migration.- Use idempotency keys, monotonic sequence numbers, and end-to-end tracing to ensure at-most-once/effective-once semantics.

Reconciliation processes:- Continuous automated reconciler: checksum/hash per business entity, per-time window, reconciliation queues for mismatches.- Reconciliation operators: automated fixes (safe), and human workflows for exceptions (tickets with context).- Maintain audit logs and replay capability from event store to rebuild state.- Periodic business-logic tests (e.g., trial balance) and Canary cohorts to validate behavior.

Monitoring & cutover readiness:- Telemetry: metrics (lag, error rates, reconciliation delta counts), traces (distributed trace IDs across legacy and microservices), logs, business KPIs.- Readiness dashboard: CDC lag < threshold, parity error rate < threshold, success rate of outbox dispatch > 99.9%, end-to-end latency SLA met.- Alerting: spike in reconciliation failures, queue backpressure, increased error budgets.- Runbook & automated rollback: feature flags to revert writes, ability to replay events to legacy, and emergency switch to Legacy-Only mode.- Pre-cutover smoke tests (synthetic transactions across flows), and a “black box” regression run.

Trade-offs & risks:- Eventual consistency simplifies migration but requires robust reconciliation.- Outbox + CDC increases operational complexity but provides reliable at-least-once delivery.- Two-phase commit provides strong guarantees but couples systems—use only where unavoidable.

This plan minimizes downtime by streaming changes, using outbox/CDC to ensure ordered reliable delivery, enforcing transactional semantics via sagas/authoritative services for critical operations, and relying on continuous reconciliation and gated cutover driven by observable readiness signals.

MediumTechnical

75 practiced

Describe how you would write an Architecture Decision Record (ADR) to capture the decision to use event-driven processing for inventory updates versus a request-response approach. Include fields you would record and an example 'consequence' section explaining trade-offs.

MediumSystem Design

94 practiced

You are given a 50k-line monolith serving 200ms average latency. The business requires a new feature to handle 3x traffic in six months. Propose an approach that includes short-term mitigation, medium-term refactor options (strangler, extract service), rollback plan, and metrics to decide whether to refactor or scale the monolith.

Sample Answer

Requirements & constraints (clarify): traffic x3 in 6 months, current p95~? SLA, peak vs sustained, budget, ops maturity (CI/CD, observability), stateful vs stateless parts of monolith, DB scalability, team size.

Short-term (weeks) — mitigation to meet near-term demand- Vertical/horizontal scale: increase instance size and count behind LB/autoscaling while monitoring costs.- Cache aggressively: add or widen CDN / in-memory caches (Redis) for hot reads, implement request/response caching and HTTP caching headers.- Rate-limit and prioritise: API throttling, graceful degradation for non-critical features, circuit breakers.- DB optimizations: add read replicas, tuning indexes, query profiling, connection pool sizing.- Fast instrumentation: add or extend metrics & tracing (latency per endpoint, DB times, error rates) and load-test plans.

Medium-term (months) — refactor / migration options1) Strangler pattern: - Identify bounded contexts / high-traffic features (use metrics). - Build new services that shadow specific routes; route traffic via API gateway to new service while keeping fallback to monolith. - Incrementally cut over and decommission code paths. - Good when you want low-risk, incremental progress and preserve existing behavior.

2) Extract service(s): - Extract stateless, well-defined domains (auth, payments, search) into microservices with separate CI/CD and DB or well-defined read replicas. - Use event-driven integration (pub/sub) or APIs for data sync; prefer asynchronous for resiliency. - Apply service contracts, observability, and automated tests.

Rollback & safety plan- Feature flags/traffic split (canary) to route % traffic to new services; ability to flip back instantly.- Blue/green deployments for new infra; keep old environment warm to avoid cold-start latency.- Automated health checks and runbooks; pre-defined KPIs for rollback triggers (error rate spike, >X ms latency, increase in error budget).- DB migration plan: use backward-compatible schema changes, dual-write slowly (write through service + monolith), and data reconciliation jobs.

Metrics to decide refactor vs scale- Cost per QPS for scaling the monolith vs estimated engineering + infra cost of refactor.- Latency and error trends under load tests (p95/p99).- Hotspots: % of traffic served by small subset of endpoints — if a few endpoints drive most load, extract them.- Deployability/velocity: time to deploy, release failure rate — if monolith slows delivery, favor refactor.- Operational complexity and SLO burn rate: if scaling increases SLO violations or cost exponentially, refactor.- Business horizon: if feature set expected to grow and require independent scaling, prefer extraction.

Recommended next steps (30/60/90)- 0–30d: Add observability, caching, DB read replicas, enable autoscaling, run load tests.- 30–90d: Identify top domains, prototype strangler for one feature with canary; measure.- 90–180d: Iteratively extract services prioritized by business value and operational gain; decommission monolith pieces as validated.

This balances short-term business needs with an incremental, low-risk migration strategy driven by measurable metrics.

MediumSystem Design

76 practiced

Design multi-tenant architecture options (database-per-tenant, schema-per-tenant, shared-schema) for a SaaS product. For each option list operational cost, tenant isolation guarantees, complexity to implement, and recommended use-cases depending on tenant size and compliance needs.

Sample Answer

Clarify requirements: expected tenant count, average data per tenant, peak QPS, compliance/regulatory needs (e.g., PCI/DSS, HIPAA), operational team size, and budget — those guide choice. Below are three common multi-tenant database strategies with trade-offs.

1) Database-per-tenant- Operational cost: High — one DB instance (or at least one database) per tenant; higher hosting, backups, monitoring, and connection pooling overhead. Automation reduces human ops but still costly at scale.- Isolation guarantees: Strong — physical/logical separation; easiest to meet strict compliance and noisy-neighbor isolation.- Complexity to implement: Medium — simple tenancy mapping, but requires orchestration for provisioning, schema upgrades, migrations, and cross-tenant queries are harder.- Recommended use-cases: Large enterprise customers, tenants with high data volume or custom schemas, strict compliance (HIPAA, PCI), customers willing to pay premium. Good when tenant count is modest (hundreds, not millions).

2) Schema-per-tenant (single DB instance, separate schemas)- Operational cost: Medium — fewer DB instances, more efficient resource usage; backup/restore is per-database so can be heavier than shared-schema but lighter than DB-per-tenant.- Isolation guarantees: Moderate to high — logical separation within same DB; requires careful RBAC and limits (e.g., row-level leaks via functions). Less resistant to some DB-level failures.- Complexity to implement: Medium–High — migration tooling must apply schema changes across many schemas; connection routing and metadata management needed.- Recommended use-cases: Mid-size tenants, moderate compliance needs, when you want better isolation than shared-schema but want to conserve resources. Good for thousands of tenants with manageable schema count.

3) Shared-schema (single DB, shared tables with tenant_id)- Operational cost: Low — best density and resource efficiency; easier to scale reads/writes with sharding or partitioning.- Isolation guarantees: Low — relies on application and DB row-level security; higher risk of accidental data exposure; harder to certify for strict compliance.- Complexity to implement: Low–Medium — simple data access patterns but requires careful query filters, testing, and possible Row-Level Security (RLS) policies to harden isolation.- Recommended use-cases: Small tenants, high tenant count (millions), SaaS with homogeneous features and low compliance burden, startups optimizing cost.

Additional considerations and patterns:- Hybrid approach: mix models (shared-schema for small tenants, schema-per or DB-per for enterprise). Use routing layer and tenant metadata service.- Operational automation: invest in CI/CD for migrations, backup/restore automation, tenant onboarding/offboarding workflows, and observability.- Scaling: shard by tenant ID, use read replicas, and offload analytics to separate data warehouse per tenant or aggregated pipeline.- Compliance: For certifications, prefer schema- or DB-per-tenant and validate backup/restore, encryption, and audit trails.

Decision pattern: prioritize compliance and isolation first (DB-per/schema-per), cost and scale second (shared-schema), and use hybrid when serving mixed tenant sizes.

Unlock Full Question Bank

Get access to hundreds of Translating Business Problems to Computational Solutions interview questions and detailed answers.

Join thousands of developers preparing for their dream job.