🏛️ System Design кейс: шардирование PostgreSQL в процессинге заказов.

Наконец сможете масштабировать ваше System Design решение на интервью💪
На хабре в разделе "Высоконагруженные системы" появилась статья по работе с хайлоад проектом.
Сокращенно - 10 000 RPS и доступность 99,99%.

Дано:
🔘Нагрузка: 10k+ RPS
🔘Latency < 20 мс p98
🔘SLA 99,99%
Данные персистентные. СУБД - PostgreSQL. Пришло время её горизонтально масштабировать. И придумывать свой механизм шардирования 🚀

👉 Несколько архитектурных решений из разбора:
➡️Без координатора шардирования
Приложение само знает, в какой шард идти. Это убирает SPOF и снижает сетевую задержку. Какой минус? Усложняет клиентскую логику.
➡️Shard key = hash(project_id, topic_id)
Даёт локальность данных и позволяет почти полностью избежать мультишардовых транзакций. Что критично для latency.
➡️Conflict-free модель записи. Данные делятся на immutable и monotonic.

💡 Интересный trade-off
Сознательный отказ от auto-sharding. Выбрали ручное управление ради предсказуемости нагрузки и контроля hot-shard’ов.

А ещё в статье про разрешение конфликтов, решардирование, разбор со схемами и алгоритмами:
https://habr.com/ru/companies/oleg-bunin/articles/985030/

📕 Изучаем и успешно проходим этап масштабирования на интервью ☺️

⚡️ - продолжать писать рецензии на статьи, посвященные разделам System Design, Архитектуре, HighLoad

MAX - System Design World 😮
VK - System Design World😮