Explain the CAP theorem and how it applies to distributed .NET services
cs-sys-004
Your answer
Answer as you would in a real interview — explain your thinking, not just the conclusion.
Model answer
CAP theorem states that a distributed system can guarantee at most two of three properties simultaneously: Consistency (every read receives the most recent write or an error), Availability (every request receives a non-error response — not necessarily the latest), and Partition Tolerance (the system continues operating when network partitions occur). In practice, network partitions are unavoidable in real distributed systems, so the real choice is CP vs AP. A CP system (e.g., etcd, ZooKeeper) will reject requests during a partition to avoid returning stale data. An AP system (e.g., Cassandra, DynamoDB) will serve stale data rather than return an error. In a .NET microservices architecture: use CP stores for financial data or user auth; use AP stores for recommendation feeds or session caches. PACELC extends CAP to also consider latency trade-offs when no partition exists (ELC: Even without partition, trade-off between Latency and Consistency).
Code example
// CP pattern: optimistic concurrency with version check (consistency preferred)
public async Task<UpdateResult> UpdateAsync(Product product)
{
var existing = await _db.FindAsync(product.Id);
if (existing.Version != product.Version)
return UpdateResult.Conflict("Concurrent update detected");
product.Version++;
await _db.ReplaceAsync(product);
return UpdateResult.Success();
}
// AP pattern: last-write-wins with timestamp (availability preferred)
public async Task SaveAsync(UserPreference pref)
{
pref.UpdatedAt = DateTimeOffset.UtcNow;
await _cassandra.UpsertAsync(pref); // may overwrite concurrent write
}Follow-up
What is eventual consistency, and how do you surface it safely in a user-facing API — e.g., what do you return when a just-created resource is not yet visible on a replica?