Предыдущая статья: Часть 3: А при чём здесь The Thundering Herd Problem?
Thundering Herd — это о бесполезной трате CPU на пробуждение “лишних” процессов, которые не смогут выполнить работу.
Dogpile Effect — это о бесполезной нагрузке на внешний ресурс (например, БД) из-за многократного выполнения одной и той же работы.
Всем привет. Недавно пришлось решать проблему идентификации пользователя по номеру телефона в маленьком стартапе, позволяющим оформлять и оплачивать заказы онлайн. Почему именно номер телефона, а не электронная почта, например, или авторизация через соц. сети? Телефон сейчас, как мне кажется, де-факто стандарт для таких кейсов - это во-первых, а во-вторых, используя телефонный номер, можно подключать разные варианты его подтверждения: от смс до звонков с дальнейшим вводом либо кода из смс, либо последних цифр звонившего номера. Думаю, тут всем знакомы подобные механики.
Изначально я сразу и предложил использовать механику с СМС-шлюзом, но так как я тут имею дело со стартапом без инвестиций, то меня попросили придумать как на первоначальном этапе можно сэкономить (в идеале обойтись на этом этапе совсем без затрат), так как основной целью запуска было тестирование бизнес-идеи.
По предварительным исследованиям целевая пользовательская аудитория продукта является пользователями мессенджера Telegram. Вот в эту сторону я и начал думать. “Коробочный” механизм авторизации через виджет Telegram не отдает номер телефона пользователя, а нам именно он и нужен. Городить велосипед по получению номера телефона по id пользователя идея не самая лучшая, поэтому я решил сделать своего ТГ-бота для механики авторизации. Я на паре сайтов уже видел подобные решения, быстрый поиск по примерам реализации этой механики не дал внятных результатов. При поиске “авторизация telegram” я наткнулся на сайт, который был первым в поисковой выдаче. Пошел смотреть как у них все устроено, рассмотрим по шагам:
Почему «метод персон» и JTBD — это неработающий инструмент, призванный лишь создавать документацию по пользовательским требованиям и оправдывать решения команд на «фактах»...
Часть 3: А при чём здесь Thundering Herd?
В конце второй части я оставил вас с интригой: почему мой AI-ассистент решил поправить лектора и предложил термин Thundering Herd (несущееся стадо бизонов)?
С нуля создаем Node.js-сервис для GitHub, который использует LLM (OpenRouter) для построчного код-ревью Pull Request. Разберем: верификацию вебхуков, борьбу с непредсказуемостью LLM и превращение хаоса в отказоустойчивый инструмент.
Часть 2: В поисках классических проявлений Dogpile Effect.
Мое "расследование" началось с самого очевидного — поиска информации по термину Dogpile Effect. Хотелось найти каноническое определение термина Dogpile Effect.
Этим постом хочу открыть серию постов по материалам курса Архитектор ПО.
Управление репликами - как избежать проблемы Dogpile при горизонтальном масштабировании и что вообще такое Dogpile.
Эта статья поможет вам создать приложение Express 5 с поддержкой TypeScript.
Вы настроите готовый к продакшну проект с помощью различных инструментов для линтинга, тестирования и проверки типов. В случае, если вы новичок в REST API, не волнуйтесь, эта статья также включает объяснения основных концепций, которые следует знать, таких как маршрутизация (роутинг) и аутентификация.
Настоятельно рекомендую писать код вместе со мной. Мы будем использовать подход "Разработка через тестирование" (test-driven development, TDD) для создания REST API, который может стать основой вашего следующего приложения Express.
Предупреждение: не сомневаюсь, что наверняка кто-то, прочитав данную статью, возжелает закидать меня тапками, но это его право, я не претендую на истину.
Я начал писать эту статью около двух месяцев назад. Писал по мере возможности и уже почти закончил, как буквально на днях было обсуждение именно этой темы с коллегами. По результатам услышанных там вопросов я добавил еще пару абзацев, чтобы постараться ответить на данные вопросы в комплексе. Эта статья лежала в черновиках с декабря 2021г, я совсем про нее забыл.
В наше время каждый слышал про Web-API и у многих это ассоциируется с REST. Однако этот многострадальный REST всегда какой-то не такой, с ним все время что-то не так.
Разработчики часто спорят и упрекают друг друга, что твой REST недостаточно REST-овый. Это стало чем-то вроде культа или даже религии. Я не планирую рассказывать о том, как правильно готовить REST, но весь материал именно вокруг этого многострадального RESTа.
Ещё в 2009 году Тим Бернерс-Ли написал веб-спецификацию под названием «Socially Aware Cloud Storage», ориентированную на защиту общественных интересов при реализации облачных хранилищ:
«Есть такая архитектура, в которой несколько сетевых или веб-протоколов собираются воедино для создания всемирной системы, где приложения (десктопные или веб) способны работать поверх уровня стандартного хранилища, предоставляющего возможность чтения/записи.
Ключевые моменты здесь в том, что главные участники (пользователи) и группы идентифицируются по URI, то есть получаются глобальными, и управление доступом к элементам хранилища выполняется с использованием этих глобальных идентификаторов. В итоге хранилище становится общедоступным ресурсом, независимым от использующих его приложений».
Несколько таких идей активно обсуждались в цифровой среде в конце 2000-х, вскоре после взрывного развития монолитных платформ эпохи Web 2.0 вроде Facebook*.
Ещё одну схожую по духу концепцию в то же время предлагали разработчики Opera, которые хотели «встроить в ваш браузер веб-сервер».
И если Opera Unite так и не обрела полноценную жизнь, на предложенную Тимом спецификацию обратили пристальное внимание через несколько лет, когда сменившие один другой кризисы конфиденциальности явно указали на необходимость повышения степени независимости и контроля со стороны пользователей в веб-среде.
Привет, Хабр! Я Катя Саяпина, менеджер продукта МТС Exolve. В прошлом посте я рассказывала, как подключить второй фактор аутентификации через звонок робота, который диктует код. А еще — как реализовать рабочее решение на Django с использованием API МТС Exolve на примере сайта бронирования.
Сегодня продолжим тему. Покажу, как это решение можно масштабировать и оптимизировать: уменьшить затраты за счет сохранения аудиокодов, повысить надежность доставки с помощью fallback-канала по SMS, автоматически подобрать голос и язык диктовки.
Как нас попытались «положить» при запуске: история одного DDoS
Всем привет Мы — команда разработки ии‑ассистента для поиска работы, это третья статья, посвященная нашему продукту.
Я уже писал о внутрянке продуктовой и технической части, поэтому сегодня решил поделиться кейсом нашего третьего запуска, когда нас атаковали хакеры..
Привет, Хабр!
В этой статье речь пойдет об интересной задаче на одном из моих проектов. Он был разработан на React для документооборота сотрудниками. Так уж вышло, что со времен старта проекта основным текстовым WYSIWYG-редактором был небезызвестный Jodit. За долгие годы было написано много кастомных плагинов, например, для работы с упоминаниями сотрудников, и нас устраивала его надежность, хоть его внешний вид был далек от идеала.
И вот однажды заказчик пришел с запросом:
Привет мир!
Сегодня поговорим о версионировании и его важности в разработке. 📚 Многие из нас используют библиотеки, фреймворки и пакеты — и одним из популярных способов отслеживания их изменений является семантическое версионирование, или SemVer! 🚀
🤔 Почему это важно?
Версии продуктов, которые мы делаем или используем, сигнализируют о состоянии изменений. Если обновление было в 2013 году, скорее всего, продукт больше не поддерживается. 📅Но даже если продукт обновляется каждую неделю, важно быть осторожным — ведь обновление может нести «breaking changes» и нарушить работу приложения 😱, что вызовет у ваших клиентов грустное лицо.
✨ Как SemVer решает проблему с «breaking changes»?
SemVer следует строго определенной структуре, которая делится на три основных части: major, minor, patch, и опциональные, дополнительные маркеры - pre-release и build.
Каждая часть представляет из себя число, и затем они соединяются через точку.
Вы тоже хоть раз ловили себя на мысли: «А может, ну его, этот Node.js — перепишем всё на Rust, и будет летать?»
Поздравляю — вы не одиноки. Я тоже через это прошёл.
В этой статье я разложу по полочкам, когда действительно стоит лезть в Rust, а когда лучше остаться на TypeScript и просто выспаться. Без фанатизма, маркетинга и с примерами из практики.
Последние 4 года я занимаюсь реализациейпроектов на PHP по DDD, используя слоистую архитектуру. Каждый раз я сталкиваюсь с одной из самых насущных проблем DDD: определение границ агрегата. Ведя разработку «как удобно», очень легко не заметить, как вся бизнес логика сосредоточилась в один «божий класс».
В этой статье я поделюсь своим опытом, как проектировать и разрабатывать по DDD, не скатываясь в «один агрегат, чтобы править всеми». Поговорю о проблемах определения границ агрегата и цены чтения, гидрации и содержания больших объектов в памяти PHP процесса.
Команда JavaScript for Devs подготовила перевод статьи о долгом пути протокола QUIC в Node.js. Четыре года сообщество ждало, пока OpenSSL откроет нужные API — и вот, с выходом версии 3.5, это наконец случилось. Уже в Node.js 25 ожидается первая реализация QUIC — шаг, к которому проект шёл почти полдесятилетия.
Всем привет, на связи Дмитрий Иванов, технический директор ВебРайз. В последнее время несколько раз сталкивались с типовой задачей в страховом секторе – необходимо разработать продуктовый каталог для страховой компании, с возможностью быстрого создания продуктов - конструктор продуктов, каталог справочников НСИ, калькулятор расчетов и страховой премии, фронт для онлайн продаж и, желательно, постпродажное обслуживание.
Всем привет! На связи Сергей Козлов, директор Мегаплана — системы управления бизнесом для небольших команд. В сентябре 2025 года мы выпустили масштабное обновление продукта: улучшили интерфейс и пересобрали тарифы. Для нового старта нам не пришлось массово нанимать новых сотрудников. Сегодня расскажу о плюсах подхода «всё своими силами». А ещё дам 5 советов тем, кто тоже задумывается о глобальном изменении продукта, но пока по каким-то причинам на него не решается.
Всем привет. Это моя первая статья на Habr. Хочу поделиться с вами своей историей, через что я прошел, чтобы устроиться на свою первую официальную работу программиста на популярном и любимом всеми языке Python. В статье будет приведена вся статистика: названия компаний, предложенные мне зарплаты, количество откликов, количество скринингов, технических собеседований, суммарно потраченное время и, конечно, результаты проделанных трудов. Возможно, вы обнаружите много воды, но по другому статья не будет полноценной.
По тексту есть достаточно много полезных лайфхаков, которые помогли мне на этом пути. Надеюсь, вы подчерпнете что нибудь для себя.
