Comments 9
Разумно, спасибо - хороший кейс для очередей, когда архитектура вытекает из особенностей нагрузки.
При чём здесь хаб "История IT"?
Сам читаю буквально пару хабов. Когда пришла пора выбирать куда опубликовать, начал просматривать все хабы на их содержимое. Первое, что увидел в История IT, личную историю человека о переходе в айти и семейной поддержке.
В итоге прочитал для себя История IT, как "какие-то истории айтишников".
Сейчас, конечно, уже прочитал подзаголовк "Занимательные истории из прошлого".
Спасибо организаторам мероприятия что позвали вас, спасибо вам, что поучаствовали. Просто меня совсем грусть-печаль берёт от последней тенденции подобных конкурсов: оценивающее жюри смотрит на что угодно - бизнес-модель, презентацию, вуз участников (чем моднее, тем выше место), яркость выступления и прочую чепуху - а на техническую реализацию особо не смотрят. Как-то на одном таком хакатоне с серьезными спонсорами первое место отдали команде с просто презентацией 🥲 У них ничего не было, кроме идеи и красивой презентации.
Статья мне тоже понравилась, делитесь еще.
Ооо, я вас прекрасно понимаю. Я рад, что мне удалось принять участие и исправить беду, которая положила бы все и никакие бизнес-метрики тут не спасут. На хакатонах сам бывал в ситуации, когда проект не проходил или занимал неутешительные места из-за плохого просчета бизнес-модели и способов монетизации
Самое главное весь фарс с упором на бизнес и впаривание настолько дошел до абсурда, что на Цифровом Прорыве (серьезный хакатон), мне удалось дойти до топ-10 не имея НИЧЕГО, кроме красивой презентации.
в реальности было бы следующее
нагрузка бы росла постепенно - внедрение в гос учреддения занимает время. изниоткуда взрывного роста пользователей не возникнет
гдето на скажем 100 пользователях появились бы первые тормоза, и ребята бы пофиксили бы это в моменте хотфиксом первого бутылочного горлышка, и это за неделю другую бы сделали очередь как вы сказали
но вообще даже на тысяче пользователей ( а это уже довольного много школ которые надо еще получить и внедрить) нагрузка была бы не очень высокая в моменте. никто никогда не жмет кнопку отправить оценки ровно в 12:00:00 по гринвичу. там будет нормальное распределение скорее всего (у когото часы отстают, у когото урок чуть раьше закончился э, а у когото затянулся и тп). сама кнопка должна отрабатывать за десятки миличекунд, тк сы говорим про сохранение маленького жсона в базу), при этом если скажем почти все учителя делают это в течении 5 минут, то это дает среднюю рпс в 3,3, но с пиком, значит в моменте нагрузка будет во много раз ниже общего числа пользователей. но вообще даже 1к рпс это довольно небольшая цифра, а мы тут говорим об какихто 100 рпс в пике.
Ну, в чем-то вы правы. Насчет того, что никто не жмёт ровно - все равно нагрузка вырастает в определённый момент и это факт.
Важно подсветить проблему и быть к ней готовым до того, как внезапно все упадет и команде начнут сыпаться шишки за это. А если это грант или договор какой-то с особыми требованиями? В лучшем случае, исправят всё в сжатые сроки по SLA, в худшем - начнут сильно голову делать сверху.
«У нас всё отлично»: как поверхностный аудит выявляет архитектурные риски на ранних этапах