Почему сайты, такие как stackoverflow с бейджами, используют некоторые типы отложенных заданий, чтобы определить, когда присудить новый бейдж?

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

Я работаю в компании по алгоритмической торговле в реальном времени. Часть того, что делает наше программное обеспечение, - это обработка рыночных данных от поставщика.

Теперь есть вещи, которые должны происходить в ответ на каждый отдельный тик рынка. У нас есть аналитика, есть триггеры безопасности, которые срабатывают в определенных случаях и т. Д.Но чего мы избегаем любой ценой, так это раздувания кода, который реагирует на рыночные события, всей этой «вторичной» логикой.

Причина здесь в том, что наши данные поступают по сети от поставщика данных, и нам нужно, чтобы этот поток данных передавался свободно без какого-либо резервного копирования. Наше программное обеспечение может обрабатывать около 10 000 рыночных тиков в секунду. Если обработка этих рыночных событий занимает слишком много времени, поток данных начинает засоряться, и наша способность реагировать на рынок как можно быстрее оказывается под угрозой.

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

Это позволяет нам иметь один поток, который очень быстро реагирует и не получает резервных копий данных, в то время как другой обрабатывает входящие события и выполняет с ними более важные вычисления. Разделение работы на две части таким образом обеспечивает бесперебойную работу.

Я допускаю, что это лишь косвенно связано с вашим вопросом, но мне кажется, что причины отказа от проверки логики, связанной со значком, при каждом действии пользователя вполне могут быть одинаковыми. Вы не хотите замедлять каждую операцию на сервере, выполняя менее критичную логику в тот самый момент, когда операция выполняется. Общая стратегия состоит в том, чтобы ваши быстрые операции оставались быстрыми (т. Е., в основном все действия пользователя) и делегировать более трудоемкую работу второстепенным процессам, которые выполняются, возможно часто , но не для каждой такой операции.

Можно сделать так, что если действие совершено и тут же отменено, это не приведет к получению жетона.

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

Периодическое задание просто генерирует новый статический контент и выполняется очень часто, но реже, чем каждый отдельный запрос страницы.