Software Architecture and Scalability Questions

Focuses on system design, pattern selection and trade off analysis for scalable software. Includes recognizing and applying design patterns such as Model View Controller, Factory and Observer, spotting architectural antipatterns, and identifying refactoring opportunities to maintain consistency across a code base. Covers algorithmic problem solving at scale, complexity and performance trade offs, and how to translate algorithmic solutions into scalable designs for marketplace platforms that must support global search, listings and booking flows. Discusses data model decisions and data store selection including relational and nonrelational options and specialized stores, consistency models such as strong consistency and eventual consistency, and the trade offs between latency, durability and operational complexity.

EasyTechnical

29 practiced

You must prioritize a large refactor (improves developer velocity) versus two high-impact new features requested by product. As the engineering manager responsible for architecture and delivery, describe your decision framework, stakeholder communication plan, and an example timeline that balances risk and delivery.

MediumTechnical

52 practiced

An external payment gateway starts failing intermittently under higher load. As EM, propose resilience patterns and operational steps (circuit breakers, retries, backpressure, fallback flows) to protect the booking system and user experience. Explain trade-offs of each approach.

MediumTechnical

30 practiced

You need to decide between denormalizing a read model (for faster reads) and maintaining normalized writes (for transactional simplicity). As an engineering manager, describe the decision criteria, migration plan, and how you would measure whether the denormalized model delivers expected benefits without unacceptable costs.

Sample Answer

**Decision criteria**

- Business need: measure read latency, throughput, and user impact (p50/p95, error rates, UI TTI). If reads dominate cost or user experience and writes are much less frequent, denormalize is favored.- Consistency tolerance: can the product accept eventual consistency? If not, avoid denorm or add compensating logic.- Complexity & operational cost: estimate engineering effort, storage cost, query simplicity, and testing surface.- Failure modes: risk of stale/incorrect data, harder updates, undo/compensation complexity.

**Migration plan (phased, low-risk)**

1. Discovery & design (1–2 sprints): define denormalized model, ownership of fields, invariants, and reconciliation rules.2. Read-only shadow (2–4 wks): build denormalized store populated from current system; route a small % of reads to compare results without affecting users.3. Gradual rollout (canary -> 50% -> 100%): route more traffic, monitor correctness, latency, and cost.4. Write strategy: keep normalized writes as source of truth; implement event-driven updates (CDC or events) to populate denorm store; include idempotent handlers.5. Reconciliation & alerts: periodic background full/partial reconciliation and automated alerts on divergence thresholds.6. Cutover & cleanup: switch default reads if metrics meet targets, then retire unused indices and code paths.

**Measurement & success criteria**

- Performance: p95 read latency reduced by target (e.g., 30–50%), throughput improved, decreased DB CPU/IO.- Correctness: divergence rate < threshold (e.g., <0.01% mismatches) and MTTR for fixes < defined SLA.- Cost: total cost (storage + ops) within budgeted delta vs benefits.- Business impact: improved user metrics (conversion, retention) or backend SLA achievement.- Operational burden: mean time to detect/reconcile inconsistencies and number of on-call incidents not increased.

If metrics fail, rollback plan: revert read routing to normalized store, pause event producers, and fix reconciliation logic before retry.

MediumSystem Design

27 practiced

Propose an event-driven architecture to propagate listing changes (price, availability, description) to downstream systems: search index, notification service, analytics, and cached pages. Include event schema considerations, idempotency, ordering, schema evolution, and how you'd ensure reliability for at-least-once delivery.

Sample Answer

**Clarify scope & goals**As an engineering manager I’d propose a resilient, observable event-driven pipeline ensuring listing change events reach Search, Notifications, Analytics, and Cache with at-least-once semantics, minimal coupling, and safe schema evolution.

**High-level architecture**- Producers (Listing Service) publish events to a durable pub/sub (e.g., Kafka, Google Pub/Sub).- A topic per domain: listings.events; consumers: SearchIndexer, Notifier, Analytics, CacheInvalidator.- Use consumer groups per downstream logical function; stream processors (Kafka Streams/Flink) for transformations.

**Event schema**- Use versioned, typed envelope: - event_id (uuid), occurred_at (iso8601), source, schema_version, listing_id, change_type (PRICE/AVAIL/DESCRIPTION), payload (nullable fields), previous_values (optional), trace_id.- JSON with Avro/Protobuf registry for schema evolution (backward/forward compatibility).

**Idempotency**- Include event_id; consumers dedupe using idempotency key (event_id) stored in short-lived cache or DB (with TTL) or use upserts with causal version (listing_version) to enforce idempotent writes.

**Ordering**- Partition events by listing_id to preserve per-listing ordering; consumers process partitions sequentially. Allow eventual consistency across different listings.

**Schema evolution**- Use schema registry and compatibility rules (backward compatible changes allowed). Consumers default unknown fields; producers should use new fields sparingly and bump schema_version.

**Reliability & at-least-once**- Durable broker, replication, and retention.- Consumer commit after successful processing; on failure, retry with exponential backoff and DLQ after N attempts.- Exactly-once processing patterns where needed (e.g., search index): use idempotent upserts with version checks (listing_version) or transactional sinks (Kafka exactly-once semantics) for critical paths.- Monitor lag, failures, DLQ size; alerting and runbooks.

**Operational practices**- Define SLAs per consumer, testing (contract tests, end-to-end), runbook for schema rollouts, and cross-team ownership for consumers/producers.

EasyTechnical

33 practiced

Explain strong consistency and eventual consistency in distributed systems. Give one concrete example of each in a marketplace (which data or operation would use each), and describe how you would document and enforce consistency expectations across teams developing services.

Unlock Full Question Bank

Get access to hundreds of Software Architecture and Scalability interview questions and detailed answers.

Join thousands of developers preparing for their dream job.