Comments 4
Первая история совсем так себе. Нормальные инженеры не будут внезапно пилить новый сервис с таким дедлайном. Они просто починят старый. Старый в продакшене, точно работает, надо просто починить.
А потом не торопясь можно и переписать если хочется.
Да банально проблема в архитектуре, при которой есть узкое горлышко и как его не масштабируй, в какой-то момент наступит предел. Там например вся информация берётся копий бд, скорость обновления между которыми всё падает из за роста числа этих копий. А их рассчет показал, что к Рождеству пользователей будет так много, что обновление во всех копиях займёт более нескольких часов, что сделает абсолютно неработоспособным всю функцию.
Это чисто пример.
Там например вся информация берётся копий бд, скорость обновления между которыми всё падает из за роста числа этих копий.
И отлично. Тупо шардируем пополам по userid составителя списка и делаем костыль который будет направлять запросы в нужную базу. Шардируем совсем по тупому. Если userid это ui64, то берем половинку от ui64 и отправляем в другую БД. Если шардов уже много, то увеличиваем их число в два раза.
Еще примерно год протянет. А там и нормально сделать можно.
Это чисто пример.
В этом и есть отличие инженера от кулстори успешного успеха инфоцыганина. Инженер просто возьмет и починит. Без подвига, без напряжения сил, попивая чаек в процессе. На любом примере.
Исключений не бывает. Все сервисы стабильно работают благодаря инженерам.
И всех потом всё равно уволили. Ничего личного, чистый бизнес
Как самоотверженные сотрудники Amazon спасали Рождество