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

Я Алексей Соболеков, лид архитектуры F&R в Magnit Tech. Это мой личный взгляд на события, и в команде существуют разные их интерпретации.

В 2024 году команда F&R (подробности тут: Архитектура высоконагруженной платформы Magnit F&R) в MAGNIT TECH  столкнулась с нетривиальным вызовом: всего за один год необходимо было вырасти с 20 до 220 человек для формирования состава команд. Формально все выглядело благополучно - проект запущен, бюджет подтвержден, приоритет высокий. Но именно с этого момента в ИТ-команде разработки F&R начали накапливаться системные проблемы.

В статье Архитектура высоконагруженной платформы Magnit F&R было рассказано о ключевых архитектурных принципах и решениях.

Сегодня хочу поделиться практическим опытом: как в Magnit Tech изменилась концепция Data Lakehouse, где она блестяще сработала — и где подвела.

Я, Алексей Соболеков, лид архитектуры F&R.

И это история о том, как красивая теория сталкивается с физикой доступа к данным.

В статье Создание собственной системы F&R в «Магните»: функциональный дизайн было рассказано о том, что компания «Магнит» столкнулась с ограничениями существующих решений класса Forecast & Replenishment, по производительности, гибкости и скорости реакции.

Так мы решили создать собственное решение.

Я Алексей Соболеков, ИТ-архитектор в Magnit Tech, расскажу о ключевых архитектурных принципах и решениях Magnit F&R. Будет полезно Архитекторам, Техлидам, CTO, и всем, кто проектирует архитектуру высоконагруженных облачных решений на базе Open Source технологий.