Умная VS глупая нагрузка. Нюансы порождения первой и уничтожения второй.
Программный комитет ещё не принял решения по этому докладу
Целевая аудитория
Тезисы
Мы знаем много о паттернах и архитектурных принципах, с помощью которых можно выполнить требования заказчика оптимальным образом. При этом, часто воспринимаем нагрузку как вред, либо как данность, с которой надо или бороться, или смириться на каком-то этапе. Производительные языки и фреймворки, и другая инженерка помогают нам в борьбе.
А что если нагрузка - больше наш друг, чем враг? К чему приведёт осознанное создание дополнительной нагрузки даже в изначально не самой нагруженной системе? И как при этом отделять полезную нагрузку от вредной, а умную от глупой...
Покажу на примере свежей реальной системы взгляд на создание нагрузки под другим углом. За пример возьмём изначально средненагруженный класс систем и применим ряд практик, которые поднимем нагрузку x10. Покажу как при этом конвертируется нагрузка из одного вида в другой, как меняется архитектура, и какие бенефиты это даёт системе и бизнесу.
За 15+ лет в IТ прошел путь от разработчика и дизайнера на фрилансе через свою веб-студию, стартап и Enterprise во всех ролях до CTO. Разработал и внедрил решения для таксопарков, страховщиков, ретейла, логистов — от частных ИП до Леруа и Почты, пока не занесло в финтех. Был архитектором крупнейшей адресной базы Почты России. В настоящее время CTO в Газпромбанке.
Видео
Другие доклады секции
Архитектура и масштабируемость
