Зачем нужен distributed SQL — горизонтальный масштаб с сохранением SQL и ACID-транзакций, как под капотом работают шардинг и консенсус (Raft у трёх движков, Paxos у OceanBase), чем платим латентностью распределённых транзакций и когда это оправдано против одиночного PostgreSQL с репликами. Все числа сняты на одном стенде: четыре движка, одинаковые замеры, назначенная задержка между узлами
Не всё в памяти — про скорость: физические данные etcd лежат на диске (persistent B+tree), в памяти — только вторичный индекс путей к ним; согласованность обеспечивает Raft, а не резидентность данных. Raft, линеаризуемые чтения, MVCC-ревизии, watch и leases — и честный разбор того, почему etcd в этой серии не шестая in-memory система, а граница таксономии, и что ломается при использовании не по назначению
Разница между ONE/QUORUM/ALL на живых числах, во сколько раз LWT дороже обычной записи и что происходит с CAS-операциями под конкуренцией
Флагманский тур по ландшафту консенсуса: осваиваем Raft, Paxos, Zab и EPaxos, воспроизводя перевыборы, сетевые партиции и цену latency в интерактивном симуляторе.
Два уровня кластеризации NATS: full-mesh routes для Core и RAFT (meta-group + per-stream) для JetStream; кворум, реплики R3, placement и как кластер переживает падение ноды без потери данных
