Архитектура подмены - как заменить процессинг, не останавливая процесс

Про архитектуру

Доклад принят в программу конференции

Тезисы

Есть расхожая фраза: "Кто не рискует, тот не пьет шампанское!" Но вот в чем вопрос - где проходит та тонкая грань, за которой оправданный риск переходит в навязчивую идею, сметающую все на своем пути? Весной 21 года моя команда столкнулась с вызовом - уйти от старого процессинга во имя нового, который будет отвечать вызовам бизнеса - выше стабильность - SLA 99,99%, рост нагрузки в 5-10 раз, масштабируемость под новые бизнесы.
Конечно же был выбор между - рефакторить старое vs писать новое. А дальше: мы были молоды - верили в правило 80/20 и не учитывали, что просадка конверсии на 0,5% - блокер к переключению с одного компонента на другой.

Я хочу провести вместе с вами ретроспективный анализ и найти ответы на вопросы:
- Зачем вообще переписывать старое? Есть ли объективные причины?
- Как аккуратно подменить такой крупный, требовательный к доступности и нагруженный кусок системы как процессинг?
- На сколько можно недооценить ресурсы на такой проект и какие проблемы может принести в соседние команды разработки?

Цель моего доклада - не призыв к переписыванию и даже не демонстрация опыта, я хочу показать путь - цели и нюансы, которые могут вас сопровождать на маршруте: "Все сжечь и написать заново". Продемонстрировать на конкретном примере, почему "быстрый старт" != "быстрое внедрение". Доклад будет полезен всем, кто стоит на распутье по выбору технической стратегии развития архитектуры нагруженных и/или высокодоступных систем, а также тем, кто будет эти стратегии воплощать в жизнь.

Михаил Натаров

ЕДИНЫЙ ЦУПИС

Архитектор, более 15 лет стажа в IT, более 10 лет проектирования доменах: FinTech, GameDev, MedTech и транспорт.

Видео