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: 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.