advanced
CAP theorem
Use CAP to discuss behavior under network partition, not as a shortcut that replaces concrete consistency requirements. Привязывайте answer к invariant, not generic theory.
CAP: при сетевом partition распределённая система не даёт одновременно линейлизуемую consistency и полную availability read и write — в этом окне CP или AP. На практике partition редки, но реальны; большинство систем PA с настраиваемой consistency.
CAP для рамки дискуссии, не вместо деталей. Какой инвариант ломается при partition: stale read, недоступность записи или разрешение конфликтов. Современные системы дают уровни consistency на операцию.
На интервью: partition для выбранной БД, без «CAP — два навсегда», связь с видимым пользователю инвариантом.
Типовые ошибки: CAP без привязки к дизайну; игнор latency как фактора consistency; partition «не бывает» в одном регионе облака.
Компромисс — гибкость против сложности: знайте, когда достаточно более простого пути.
Чеклист:
- Поведение при network partition.
- CP или AP trade для вашего store.
- Связь с конкретным требованием consistency.
- Настраиваемая или session consistency.