«Когда-то кто-то очень жестко облажался в проде» 😁
Чем больше изучаешь System Design, тем сильнее понимаешь, что большинство паттернов - это сборник чужих ошибок, за которые кто-то уже заплатил бессонными ночами, сорванными релизами и очень неприятными созвонами 😐
🟣 Возьмем Circuit Breaker, сначала кажется, что это какая-то сложная архитектурная штука. На практике идея максимально простая: если соседний сервис начал умирать, не надо его добивать своими запросами
Потому что, как обычно происходит: один сервис начал отвечать по 5 секунд вместо 100 мс, остальные продолжают в него ломиться, забивают свои пулы потоков, начинают тормозить сами, и через пару минут уже лежит половина системы
Circuit Breaker буквально говорит:
«Брат, ему плохо. Отстань от него на пару минут»
И это спасает прод гораздо чаще, чем кажется
🟣Или Saga - очень популярная тема на собеседованиях. Пока работаешь с монолитом, транзакции выглядят как magic, если что-то пошло не так - откатились и всё ок, но потом появились микросервисы: деньги списывает один сервис, заказ создает второй, товар резервирует третий
И внезапно оказывается, что общего rollback больше не существует ☹️
Если деньги уже списались, а резерв товара упал, кто будет все откатывать назад? Спойлер: ты
Поэтому Saga работает по другому принципу: она не откатывает действия назад, она запускает компенсирующие действия
Списали деньги? Значит нужно сделать возврат
Создали заказ? Нужно отменить заказ
Зарезервировали товар? Значит нужно снять резерв
То есть вместо одного большого rollback появляется цепочка бизнесовых отмен. И именно поэтому Saga одна из самых популярных тем в микросервисах. Потому что рано или поздно почти каждый проект сталкивается с вопросом:
"А что делать, если половина процесса уже выполнилась, а вторая половина сломалась?"
🟣 Еще один паттерн, который очень любят интервьюеры - CQRS (Command Query Responsibility Segregation)
На деле идея довольно бытовая, очень часто системе нужны совершенно разные подходы для чтения и записи данных. Например, заказ создается один раз, а читается потом тысячу раз. И в какой-то момент становится выгоднее иметь отдельную модель для записи и отдельную для чтения, чем пытаться заставить одну схему хорошо делать всё сразу
Но когда впервые встречаешь эту аббревиатуру, кажется, что это какой-то секретный раздел математики
🟣 Дальше идет шардирование, с ним обычно начинают разбираться, когда база уже начинает становиться узким местом системы
Выглядит всё просто:
если одна база не справляется, давайте разделим данные между несколькими
Но вместе с нагрузкой распределяются и сами данные. Теперь нужно думать, как находить нужный шард, что делать с запросами не по shard key и как избежать ситуации, когда один шард плавится под нагрузкой, а остальные почти ничего не делают 🥺
Поэтому шардирование - это не волшебная кнопка для ускорения базы, это способ решить одну большую проблему с масштабированием ценой нескольких новых проблем, с которыми потом придется жить. Подробнее про шардирование рассказывал в этом посте 👀
🟣Ну и конечно Outbox Pattern, рано или поздно почти каждый проект приходит к связке БД + Kafka. И тут выясняется, что PostgreSQL вообще не знает, что такое Kafka, а Kafka не знает, что происходит внутри транзакции PostgreSQL 🙄
И если приложение упадет между сохранением данных и отправкой события, можно легко получить рассинхрон между сервисами
Собственно, Outbox появился ровно потому, что кто-то однажды потерял достаточно много событий и понял, что так жить больше нельзя
На собесах почти никогда не спрашивают сами паттерны, обычно дают какую-нибудь неприятную ситуацию: упал сервис, потерялось событие, одна база перестала вывозить нагрузку и так далее
И если ты понимаешь, почему эта проблема вообще появилась, нужный паттерн обычно вспоминается сам, поэтому паттерны полезно учить не как список определений, а как каталог чужих катастроф
P.S.Чекни карточки, там каждый паттерн расписан, а если пост зашел - накидай 🔥, сделаю вторую часть