Масштабирование записи

Проблема

Многие задачи по системному дизайну начинаются со скромных требований к нагрузке, прежде чем интервьюер бросит вызов: "а как это будет масштабироваться?". Хотя вы можете быть знакомы с подходами для масштабирования чтения (например, репликация, кэширование и т. д.), сторона записи часто представляет собой гораздо более сложную задачу.

Высоконагруженная запись со всплесками и высокой конкурентностью может стать кошмаром для архитектуры, и есть множество различных подходов, которые могут помочь справиться с ней или сделать ситуацию хуже. Интервьюеры любят исследовать узкие места в вашем решении, чтобы увидеть, как вы отреагируете на резкий рост нагрузки.

В этом паттерне мы пройдемся по различным сценариям и проблемам, которые стоит ожидать на интервью по System Design, и поговорим о стратегиях, которые можно использовать для масштабирования системы.

Решение

Масштабирование записи - это не только "добавим больше железа". Существует ряд архитектурных решений, которые улучшают способность системы к масштабированию. Комбинация четырех стратегий позволит вам масштабировать запись за пределы того, что может обработать одна неоптимизированная база данных или сервер:

1. Вертикальное масштабирование и выбор базы данных
2. Шардирование и партиционирование
3. Обработка всплесков с помощью очередей и сброса нагрузки (load shedding)
4. Пакетирование (batching) и иерархическая агрегация

Сначала разберем, как масштабироваться, оставаясь в пределах архитектуры "один сервер + одна база", и только потом перейдем к горизонтальному масштабированию.