What is the CAP theorem in distributed systems? Explain what each letter stands for, give a concrete example of a system that sacrifices each property, and explain why you can't have all three.

Judge: Accurate definitions with CP (etcd/ZooKeeper), AP (Cassandra/Dynamo), and CA (single-node Postgres) examples, plus a clear partition-forces-the-choice explanation and the correct nuance that P is non-optional. Complete and well-structured.

Judge: Accurately defines all three letters, correctly frames the partition-forced C-vs-A tradeoff, and gives valid AP (Cassandra/Dynamo) and CP (etcd/ZooKeeper) examples plus the CA single-node case. The two-replica partition walkthrough clearly explains why all three cannot hold. Both hard constraints met.

Judge: Defines all three letters correctly, gives valid AP (Cassandra) and CP (ZooKeeper) examples and the CA single-node case, and explains the impossibility with a concrete partition scenario. Accurate and clearly structured; both hard constraints satisfied.

Judge: Defines all three properties precisely, gives valid CP examples (ZooKeeper/etcd) and AP examples (Cassandra/Riak), plus the single-node CA case, and walks through a concrete two-node partition scenario showing why C and A cannot both hold. It even includes the correct modern nuance that the tradeoff only binds during partitions. Accurate, deep, and well-structured.

Judge: Defines all three letters precisely (including the linearizability vs ACID distinction), gives valid CP (ZooKeeper, etcd, HBase) and AP (Cassandra, DynamoDB, CouchDB) examples, correctly frames CA as the degenerate case, and walks through the two-node partition scenario that forces the C/A choice. The PACELC extension and practical CP-vs-AP guidance add genuine depth. Fully satisfies every prompt requirement.

Judge: Thorough and accurate explanation of CAP theorem. Correctly defines all three properties with appropriate nuance (linearizability for C, partition tolerance as practical necessity). Provides concrete examples: ZooKeeper/etcd for CP, Cassandra/DynamoDB for AP, single-node DB for CA. The 'why you can't have all three' scenario with two nodes is clear and well-constructed.

Judge: Accurate definitions of all three CAP properties. Valid examples for each tradeoff: PostgreSQL as CA, ZooKeeper/etcd as CP, DynamoDB/Cassandra as AP. The 'why you can't have all three' explanation uses a concrete two-datacenter scenario that makes the forced choice between C and A during partition intuitive. Includes the important nuance that partitions are inevitable so the real choice is C vs A. The closing note about CAP being misunderstood adds sophistication.

Judge: Accurate definitions of all three CAP properties. Valid examples for each archetype: HBase/MongoDB for CP, Dynamo/Cassandra for AP, single-node RDBMS for CA. Clear explanation of why you can't have all three -- network partitions are inevitable, forcing a choice between C and A. Well-structured with the 'why' section at the end that ties everything together.

Judge: Accurate definitions of all three properties. Correctly explains that partition tolerance is non-negotiable in real systems, making the real choice C vs A. Good system examples (Cassandra/DynamoDB for AP, MongoDB/Zookeeper for CP). The 'why you can't have all three' explanation is clear and concise. Mentions tunable consistency as a modern nuance. Covers all requested elements.

Judge: Accurate definitions of all three properties. Good explanation of why partition forces the C/A choice. CP example (PostgreSQL) and AP example (DynamoDB/Cassandra) are valid and well-explained with diagrams. The CA example correctly notes the impracticality. Minor: could go deeper on why 'P' is non-negotiable in practice.

Judge: Accurate definitions of C, A, and P. Good examples: DNS for AP, PostgreSQL sync replication for CP. The 'why you can't have all three' explanation correctly frames the partition scenario and the forced C/A choice. The CA example (single-datacenter RDBMS) is the standard caveat. Minor: could note that P is non-optional in distributed systems (Brewer's later clarification), but the core explanation is sound.

Judge: Correctly defines all three letters (C, A, P) and provides examples of CP (Spanner) and AP (DynamoDB) systems, meeting both hard constraints. The explanation of why you can't have all three is clear — partition tolerance is non-negotiable, forcing a C/A tradeoff during partitions. The examples are reasonable though Spanner is debatable (Google markets it as having all three via TrueTime). Response is truncated before completing the third example.

Judge: Accurate definitions of all three letters, reasonable system examples (Dynamo/Bigtable for AP, PostgreSQL for CP). The explanation of why you can't have all three during a partition is solid. Minor imprecision: the availability definition ('every request receives a response, without guaranteeing correctness') conflates availability with a weaker property. Good structure and clarity overall.

Judge: Correct definitions of all three CAP properties with reasonable system examples (MongoDB as CP, Cassandra as AP). However, the explanation of WHY you can't have all three is shallow -- states the tradeoff without walking through a concrete partition scenario that forces the choice.