Loading
Pick a focused question that fits your time, stack, and interview goal.
12 results across 1 active filter
Page 1 of 1
Maps business invariants and stale-data tolerance to strong or eventual consistency, explicit failure behavior, reconciliation, and user-visible state.
Designs a multi-service business workflow using local transactions, durable progress, idempotency, retries, and domain-specific compensation.
Designs a sharding strategy with a stable key, balanced load, routing, resharding, cross-shard limits, and operational ownership.
Chooses safe cached, partial, pending, read-only, or unavailable behavior and makes degraded state explicit to clients and operators.
Uses read replicas selectively while accounting for stale reads, read-after-write behavior, routing, failover, query cost, and replication health.
Frames a vague system-design problem with explicit flows, constraints, scale estimates, and measurable quality targets before selecting components.
Uses per-dependency concurrency limits, queues, pools, and workload partitions to stop one failing path from exhausting the whole API.
Chooses between a modular monolith and microservices using domain boundaries, team ownership, scaling, deployment, data consistency, and operational cost.
Repairs a workflow when a remote operation may have succeeded but local state, messages, and callbacks disagree.
Explains how Aspire references inject resource configuration, how logical service names resolve, and why dependency wiring differs from startup readiness.
Selects synchronous calls, asynchronous messaging, or a deliberate combination based on user feedback, coupling, latency, durability, and failure behavior.
Explains Aspire as a code-first application model and developer experience without confusing it with a production runtime or architecture style.