Hacker News Digest

В августе GitHub пережил два крупных сбоя: 6‑го и 17‑го число сервисы, включая сайт, аутентификацию, Actions, API, Pull Requests, Issues и Copilot, были недоступны почти восемь часов. Причиной стал резкий рост нагрузки, превысивший возможности центрального дата‑центра в США, где ключевой компонент не смог масштабироваться. Восстановление потребовало перераспределения трафика, изоляции проблемного оборудования и поэтапного возврата сервисов; ошибки в Copilot‑службах даже вызвали бесконечные повторные попытки клиентов, усугубив нагрузку.

В ответ компания ускорила инвестиции в ёмкость: за последние месяцы добавили более 3 млн процессорных ядер, 120 петабайт высокоскоростного хранилища и значительный сетевой ресурс, перенёс часть нагрузки в Azure (сейчас 58 % платформенного трафика обслуживается там). Были введены ограничения на повторные запросы, бюджеты таймаутов и пересмотрены низкоприоритетные оповещения, чтобы избежать каскадных сбоев. Тем не менее, рост активности — 2,9 млрд коммитов в месяц и 24 млн новых репозиториев — требует дальнейших архитектурных изменений, чтобы гарантировать надёжность, без которой разработчики не могут создавать и выпускать программное обеспечение.

Сбой GitHub вызван не нехваткой емкости, а отсутствием отказоустойчивости: системы коллапсируют при перегрузке, вместо того чтобы отбрасывать низкоприоритетный трафик. Клиентские retry-циклы, особенно в VS Code, усилили нагрузку в 10 раз и замедлили восстановление — это системная проблема, а не баг. Рост коммитов с 1,4 до 2,9 млрд в месяц за несколько месяцев указывает на массовое внедрение AI-агентов, что не было учтено при проектировании инфраструктуры. Рост CPU и хранилища не решает проблему — если архитектура не предусматривает graceful degradation, масштабирование лишь откладывает катастрофу. Нужно выставлять алерты при 80% загрузки, отслеживать лимиты не только сервисов, но и sidecar-контейнеров (например, Istio). Внедрять client-side throttling: при 5xx клиенты должны замедлять запросы, а не перезапрашивать. Трафик отдельных клиентов должен изолироваться, чтобы перегрузка одного не затрагивала других, особенно платных. Прогнозирование нагрузки (как в CloudWatch) важнее реактивного масштабирования. GitHub стал уязвимым централизованным монополистом — его сбой затрагивает всю экосистему, что стимулирует альтернативы: децентрализованные форки и локальные системы код-ревью. Платформа, скрывающая ошибки под спиннерами, нарушает принцип прозрачности для разработчиков. Рост GitHub Actions в выходные показывает, что AI-автоматизация затронула и личные проекты. Споры: разделить бесплатные и платные репозитории, чтобы enterprise-клиенты не страдали от AI-трафика — или сохранить открытость? Ввести плату за коммиты — или считать убытки GitHub оправданными, если они стимулируют Azure и OpenAI? Разработка AI-агентов для оптимизации внутренней инфраструктуры логична, но компания фокусируется на внешних функциях, а не на стабильности.

Мы заменили Redis‑хранилище резервов на MySQL и смогли выдержать нагрузку в $5,1 млн продаж в минуту в 2025 году.
Ключевая идея — по одной строке на каждый товарный остаток, а не на одну строку на товар с колонкой количества. Это позволило использовать SKIP LOCKED, получая конкурентный доступ к отдельным единицам и избегая конфликтов при одновременных покупках.

Получилось два важных вывода. Во‑первых, старые ограничения (одна строка‑количество) устарели: современные версии MySQL уже поддерживают нужный уровень изоляции, и их стоит перепроверить при росте нагрузки. Во‑вторых, простая прототипная проверка (небольшой скрипт, мониторинг блокировок) раскрыла реальный узел — избыточное использование соединений, а не «медленные» запросы. В итоге система стала надёжнее: больше нет перепродаж и больше завершённых покупок, а база остаётся здоровой для всех остальных процессов.

Тред критикует подход Shopify к резервированию товаров, предлагая альтернативы: отдельная строка на заказ-товар или фоновый возврат товаров в запас. Участники согласны, что денормализация повышает производительность, но может вызывать проблемы с согласованностью и блокировками. Рекомендуется шардирование таблицы запасов по ID магазина для снижения нагрузки. Некоторые считают Shopify шагом назад — вместо Redis используется диск-ориентированная БД, не справляющаяся с десятками тысяч одновременных соединений. Хотя готовые решения проще, в данном случае они могут быть неоптимальны.

PlanetScale анонсировал запуск однодневного режима своей базы данных по цене $5 в месяц. Новая конфигурация PS-5 предназначена для разработки, тестирования и некритичных рабочих нагрузок, предлагая вертикальное масштабирование без добавления реплик. Это значительно дешевле предыдущего минимального тарифа в $30 за 3-узловой кластер с высокой доступностью. Компания отмечает, что ежедневно получает запросы на более доступный тариф для разработчиков на начальном этапе.

Новая структура ценообразования включает различные типы узлов (PS-5, PS-10) как в однодневном, так и в HA-режиме. Клиенты могут начать с малого и масштабироваться до гипермасштабирования без смены платформы базы данных или сложной миграции. Запуск новой функции запланирован на ближайшие пару месяцев, а желающие могут зарегистрироваться для получения уведомлений о доступности.

• Пользователи вспоминают, как PlanetScale отменил бесплатный тариф, что стало причиной увольнения сотрудников и изменения дизайна сайта.
• Некоторые участники обсуждения считают, что отсутствие бесплатного уровня делает невозможным тестирование сервиса, в то время как другие подчеркивают, что бесплатные продукты неустойчивы и могут быть отменены в любой момент.
• Обсуждается, что цена в 5 долларов за базу данных может быть недостаточной для покрытия затрат на обеспечение высокой доступности и репликации, что вызывает вопросы о долгосрочной жизнеспособности таких планов.
• Некоторые участники обсуждения высказывают мнение, что отсутствие бесплатного уровня может отпугнуть новых пользователей, в то время как другие считают, что это может быть выгодно для компании в долгосрочной перспективе.

• Старая мантра: «Делай то, что не масштабируется». Раньше это был первый шаг к будущему росту.
• Новая реальность: с GPT и Cursor вы просто останавливаетесь на первом шаге. Проект, который раньше занимал выходные, теперь собирается за вечер. Если он решает задачу для меня и пары друзей — уже успех.

Маленький Slack

Сто человек, 15–20 активных в неделю. Все знают друг друга в лицо, делятся тем, что не выложишь в паблик. Добавить ещё 900 — и интимность исчезнет. Рост ухудшит продукт.

PostcardMailer

Первый вариант: пост в Instagram → автопочтовая открытка маме. API убили, сделал загрузку вручную. Появились спам и Tor — закрыл регистрацию. Heroku устарел — переписал на e-mail:
фото → mom@postcardmailer.us, подпись в теме. Никаких сайтов, паролей, публичного доступа.

Landline-напоминалка

Мама без смартфона, только стационарный. Скрипт на Twilio звонит трижды в день: «Время таблеток», через 10 минут — «Точно приняли?». Стоит копейки, написано за вечер. Масштабировать — значит влезать в чужие семьи и суды. Версия «только для мамы» — идеальна.

Формула

1. Заметить свою боль.
2. Собрать минимальное решение.
3. Оставить его маленьким.

• Участники обсуждают, что делать «вещи, которые не масштабируются», стало проще и приятнее благодаря ИИ-ассистентам: они ускоряют прототипирование и снижают порог входа.
• Однако многие отмечают: такие pet-проекты существовали и до LLM; настоящая ценность ИИ — в преодолении «белого листа» и экономии времени, а не в изобретении самого подхода.
• Тезис «не обязано масштабироваться» применим не только к хобби, но и к компаниям: можно быть прибыльным «Small Giant» вместо гонки за «хоккейной клюшкой».
• Массовый рост часто убивает атмосферу и узнаваемость сообщества, поэтому «остаться малым» — осознанный выбор.
• Итог: ИИ дал миллионам возможность быстро готовить «home-cooked apps» для себя и узкого круга, не ставя задачи покорить рынок.