Architecture and Technical Trade Offs Questions

Centers on system and solution design decisions and the trade offs inherent in architecture choices. Candidates should be able to identify alternatives, clarify constraints such as scale cost and team capability, and articulate trade offs like consistency versus availability, latency versus throughput, simplicity versus extensibility, monolith versus microservices, synchronous versus asynchronous patterns, database selection, caching strategies, and operational complexity. This topic covers methods for quantifying or qualitatively evaluating impacts, prototyping and measuring performance, planning incremental migrations, documenting decisions, and proposing mitigation and monitoring plans to manage risk and maintainability.

MediumTechnical

28 practiced

For a product with web, iOS, and Android clients that require aggregated views combining multiple services, evaluate API gateway, client-side composition, and Backend-for-Frontend (BFF) patterns. Discuss trade-offs in latency, caching, developer productivity, code duplication, schema evolution, and operational complexity. Recommend which to use and why for a platform with multiple internal product teams.

Sample Answer

**Short answer / recommendation**Use a hybrid: an API Gateway for cross-cutting concerns (auth, rate limit, routing, coarse caching) plus per-platform Backend‑for‑Frontend (BFF) services for aggregated views. This balances latency, developer productivity, and team autonomy while containing operational complexity.

**Trade-offs by pattern**

- API Gateway - Latency: low if gateway only routes; can add aggregation to reduce chattiness but risks higher latency if it orchestrates many services. - Caching: good for shared, coarse cache at edge. - Dev productivity: centralizes contracts — faster for infra teams, slower for product teams if gateway becomes bottleneck. - Code duplication: low if gateway handles common joins. - Schema evolution: central point simplifies compatibility but becomes a coordination chokepoint. - Ops complexity: moderate; single deploy surface but may require complex routing/transformations.

- Client-side composition - Latency: higher due to multiple round-trips; worse on mobile networks. - Caching: per-client caches possible but inconsistent. - Dev productivity: fastest for full-stack teams wanting direct control; burdens UI teams with integration logic. - Code duplication: high across web/iOS/Android. - Schema evolution: each client adapts independently — flexible but noisy. - Ops complexity: low server-side but increases client maintenance overhead.

- BFFs (per-platform) - Latency: optimized—single call from client to BFF; BFF can parallelize and aggregate backend calls. - Caching: BFFs can implement platform-specific caching strategies (short-lived, view-level). - Dev productivity: high for product teams—BFFs owned by teams, iterate quickly on view models. - Code duplication: minimized across clients (shared view logic centralised per platform); some duplication across BFFs possible. - Schema evolution: BFFs shield clients from backend changes; enable gradual evolution. - Ops complexity: higher than pure gateway — more services to operate, but bounded by team ownership.

**Why hybrid for multiple internal product teams**- Multiple teams need autonomy to iterate on view models and experiments—BFFs give that while keeping clients lightweight.- API Gateway handles security, telemetry, global caching and route management to avoid duplicating infra logic across BFFs.- This minimizes client-side duplication and poor mobile latency, accelerates developer velocity, and lets individual product teams evolve schemas behind their BFFs.

**Operational recommendations**- Standardize BFF templates, logging, and contract testing to reduce duplication and ops burden.- Use API gateway for cross-cutting policies + lightweight aggregation where beneficial.- Define clear ownership: product teams own BFFs; platform team owns gateway and shared libraries.

MediumTechnical

27 practiced

As a TPM evaluating whether to adopt microservices with a small, less experienced engineering team, propose a decision framework. List concrete technical and organizational criteria to weigh (coupling, deployment velocity, ops maturity, testing practices), short-term and long-term trade-offs, and an incremental adoption plan if you decide to move toward microservices.

HardSystem Design

38 practiced

You need to split a hot shard of a user table to reduce write contention and improve throughput without downtime. Describe a migration plan covering rekeying or range-splitting strategy, routing writes and reads during migration, data copy verification, handling concurrent writes, rollback approach, monitoring metrics, and automation considerations for repeatability.

Sample Answer

**Clarify goals & constraints**- Goal: reduce write contention on a hot shard with zero downtime, preserve consistency (read-your-writes), and be reversible.- Constraints: DB type (range vs hash), transaction semantics, latency SLOs, maintenance windows, cross-team owners.

**Strategy: rekey vs range-split**- If shard is range-keyed and hot key ranges exist → perform a range-split (split the problematic key range into two new ranges).- If sharding is hash-based or uneven key hot-spot → rekey (move specific hot user IDs to new shard(s) using a new shard key or virtual shards).

**Routing during migration**- Deploy a routing layer change controlled by feature flags: - Dual-routing for reads: route reads to original shard; for reads-after-write consistency, route reads for affected keys to the new shard once write-forwarding stable. - Writes: implement a safe write-forwarding pattern — write to both old and new shards (idempotent), or write to new shard and asynchronously replicate to old until cutover. - Use a canary subset of keys/users first.

**Data copy & verification**- Bulk copy existing key-range (consistent snapshot if supported) into target shard.- Verification steps: - Row counts, checksums (per key-range), sample key diff, and end-to-end application-level checks. - Run background incremental sync (change-logs) to catch concurrent updates.

**Handling concurrent writes**- Use ordered change-log (CDC) to replay concurrent writes into target.- For dual-write, make writes idempotent and include write-version or last-writer timestamp; detect divergence and reconcile via CDC.- For strong consistency needs: use a short “quiesce” window on affected keys using per-key locks or optimistic retry and surface transient failures gracefully.

**Cutover & rollback**- Cutover: once verification and sync lag are zero, flip routing flag for production traffic for affected keys.- Rollback: maintain replayable CDC stream and keep old shard writable for a time. If rollback required, redirect writes back and replay missing events into old shard.- Predefine SLOs and abort conditions (e.g., error rate > X%, replication lag > Y ms).

**Monitoring & metrics**- Track: write QPS per shard, 99/95 latency, error rate, replication lag, checksum mismatch count, retry rates, business metrics (order throughput).- Dashboards and automated alerts; runbook with escalation steps.

**Automation & repeatability**- Encapsulate steps in CI/CD pipelines and orchestration jobs: - automated snapshot + copy + checksum + CDC replay + gating health checks.- Parameterize for key ranges or shard IDs; include dry-run and canary modes.- Post-mortem template and audit logs for each migration.

**Stakeholders & rollout**- Coordinate DB engineers, SRE, client SDK owners; schedule canary, review runbooks, communicate developer impact.- Define success metrics (reduced write latency by X%, error < Y) and sign-off criteria.

This plan balances operational safety, verifiability, and automation so migrations can be executed repeatedly with low risk.

MediumTechnical

26 practiced

Design schema evolution and API contract practices for a platform with many dependent teams. Discuss backward and forward compatibility strategies, contract testing, deprecation policies, change windows, and tooling such as OpenAPI, Protobuf, or a schema registry. Explain how to enforce these practices across teams and measure compliance.

Sample Answer

**Situation & goal (brief):**As a Technical Product Manager for a shared platform, I’d establish company-wide schema evolution and API contract practices so dependent teams can change services safely while minimizing outages and integration debt.

**Principles**- Backward compatible = consumers continue to work without code change.- Forward compatible = new clients can tolerate older servers.- Strong contracts, automated verification, and clear deprecation timelines.

**Strategies**- Versioning: prefer semantic compatibility over coarse major-version bumps. Use minor compatible changes (add optional fields) without changing wire format. Major breaking changes require migration plan.- Compatibility rules: allowed changes (add optional fields, non-breaking enum additions with defaults), disallowed without coordination (removing fields, changing types, renaming).- Backward & forward tactics: use Protobuf with explicit field numbers or OpenAPI with "nullable/required" rules; avoid ad-hoc JSON shapes.

**Contract testing & tooling**- Central schema registry for Avro/Protobuf + Git-backed OpenAPI hub.- CI gates: consumer-driven contract tests (Pact or Spring Contract), provider tests validating consumer expectations, and schema-compatibility checks in PR pipelines.- API gateway enforces OpenAPI docs; automated mock servers for consumer testing.

**Deprecation & change windows**- Publish deprecation announcement + migration guide, set minimum 3 release cycles and an SLA for removal.- Coordinate change windows (weekly or sprint-aligned) and a "breaking change blackout" during peak business periods.

**Enforcement & governance**- Platform-owned CI templates and linters; merge blocks for incompatible schema changes; dashboards surfaced in engineering portal.- Quarterly API review board for exceptions and roadmap alignment.

**Metrics to measure compliance**- % of APIs with OpenAPI/Protobuf in registry- % PRs passing contract checks- Number of consumer breakages in production- Time-to-migrate deprecated fields- Number of blocked merges due to compatibility violations

This balances developer agility with platform stability and gives measurable levers to drive adoption across teams.

HardSystem Design

50 practiced

Design a multi-tenant API platform that must provide performance isolation and cost efficiency for tenants ranging from hobby projects to enterprise customers. Compare logical isolation (namespaces, row-level separation) versus physical isolation (dedicated clusters or VMs). Discuss tenancy allocation strategies, noisy-neighbor mitigation, billing and metrics, compliance considerations, and migration strategies between isolation levels.

Sample Answer

**Clarify requirements & goals**- Primary goals: strict performance isolation for enterprise, cost-efficiency for small tenants, predictable billing, regulatory compliance (e.g., PCI, HIPAA).- SLAs: latency P95, throughput, uptime tiers per tenant.

**High-level approach**- Offer hybrid tenancy: logical isolation by default; physical isolation for paid tiers or sensitive workloads.- Provide transparent self-service upgrade/downgrade paths.

**Logical vs Physical isolation (comparison)**- Logical (namespaces, row-level, shared pool) - Pros: low cost, high density, easier rollout. - Cons: weaker isolation; requires strong resource capping and query controls.- Physical (dedicated VMs/clusters) - Pros: strong performance and compliance boundaries. - Cons: higher cost, slower provisioning, less efficient resource utilization.- Recommendation: default logical for hobby/SMB; physical for enterprise/regulated.

**Tenancy allocation & noisy-neighbor mitigation**- Allocation: SLA-based placement engine that considers resource quotas, historical usage, and burst patterns.- Mitigation: per-tenant CPU/memory cgroups, rate limits, query timeouts, connection pools, adaptive autoscaling, isolated scheduling for noisy tenants, circuit breakers, and priority queues.

**Billing & metrics**- Metrics: per-tenant P95 latency, CPU, memory, I/O, request count, error rate.- Billing: base subscription + usage-based components (compute seconds, requests, storage) with premium for dedicated clusters.- Expose dashboards and cost alerts; map resource usage to cost units.

**Compliance & security**- Physical isolation mapped to compliance labels; encryption at rest/transit, audit logs, tenant-specific key management, IAM roles, and periodic attestation.

**Migration strategy**- Lift-and-shift logical → physical: snapshot data, warm-up traffic on dedicated infra, blue-green cutover, rollback plan.- Physical → logical: ensure resource footprints fit quotas, run compatibility tests, throttle ramp-down.- Automate migration via orchestration playbooks and surface estimated cost/impact in UI.

**Trade-offs & roadmap**- Start with strong telemetry, automated placement, and clear pricing to encourage self-selection. Invest in fast provisioning of dedicated infra to reduce enterprise friction.

Unlock Full Question Bank

Get access to hundreds of Architecture and Technical Trade Offs interview questions and detailed answers.

Join thousands of developers preparing for their dream job.