CAP-теорема (Brewer, 2000): распределенная система не может одновременно гарантировать все три свойства:

• Consistency - все узлы видят одни и те же данные в один момент времени
• Availability - каждый запрос получает ответ (не обязательно актуальный)
• Partition tolerance - система работает при потере связи между узлами

В реальных системах сетевые разделения неизбежны, поэтому выбор между C и A:

// CP-система (PostgreSQL, etcd, ZooKeeper):
// При разделении - отказывает в обслуживании, но не отдает
// устаревшие данные. Подходит для финансов, конфигурации.

// AP-система (Cassandra, DynamoDB, DNS):
// При разделении - продолжает отвечать, но данные могут быть
// устаревшими. Подходит для кеширования, метрик.

// На практике: eventual consistency - данные
// со временем становятся согласованными

В Go-микросервисах CAP влияет на выбор хранилища и стратегию согласованности между сервисами (strong vs eventual consistency).