Система для работы с данными клиентов Сбера насчитывает порядка 30 ТБ данных, при этом нагрузка системы составляет 30 тысяч транзакций в секунду на чтение и 5 тысяч на запись.

За время работы над системой мы несколько раз меняли архитектуру. А точнее — 5 раз переписали систему, работающую в продакшене, и не совершили роковых ошибок.

Цель этих изменений — обеспечить отказоустойчивость, готовность системы к работе с увеличивающейся нагрузкой и возможность работать в режиме 24x7.

На примере наших fail stories мы расскажем, как избежать технических и архитектурных ошибок при построении распределенной системы и что делать, если они все-таки допущены. Вы узнаете:

• почему не стоит хранить иерархичные данные в документоориентированном хранилище;
• почему не стоит выбирать малоизвестный формат хранения данных (Oracle Nested Tables);
• что делать, когда индексы оказались не селективными;
• все про «бег впереди паровоза» — появление СУБД и прикладное шардирование для Oracle и Postgres;
• как оптимизировать хранение архивных данных;
• как сбор номера строки заставил уменьшать глубину стеков — логирование ценою в секунды;
• как мигрировать в облако и остаться на плаву — проблема с ресурсами в Openshift, отказ от Spring и переход к нативным образам, ограничение нагрузки, Istio.