Hacker News Digest

• Проблема: боты OpenAI, Anthropic, Google и др. генерят до 45 % трафика сайтов, но не приносят денег и ломают инфраструктуру.
• Последствия: сервера перегружаются, счета за трафик растут, а доход от рекламы не покрывает расходы.
• Решения: блок-листы, rate-limit, Cloudflare Bot Management, «умные» robots.txt и платные API.

• Агрессивные AI-боты превратились в DDoS: малые сайты лежат, счета за трафик вырастают в разы, хостинги выгоняют клиентов.
• Компании вроде Anthropic/Claude и «мелкие» стартапы не соблюдают rate-limit, не кешируют и маскируют ботов, хотя технически могли бы всё сделать правильно.
• Админы вынуждены ставить CAPTCHA, login-wall, ASN-блоки, rate-limit и Cloudflare, что ломает accessibility и приватность для людей.
• Пользователи ищут обходы: кто-то уходит к AI, кто-то отказывается от сайтов с капчами.
• Общий вывод: боты «пьют молочный коктейль» открытого веба, пока сами компании не несут последствий.

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

Многие инженеры мечтают о «идеальной» архитектуре: масштабируемой, распределённой, красивой. Это ошибка. Лучше глубже понять текущую систему и сделать самое простое решение.

Простое может выглядеть скучно
Джуны любят рисовать сложные схемы из кэшей, очередей, прокси. Настоящее мастерство — уметь делать меньше. Великий дизайн выглядит тривиально: «О, задача оказалась простой».
Unicorn и стандартный Rails REST API — примеры: всё нужное достигается очевидными средствами.

Практика
Нужно ограничение частоты запросов в Go-сервисе?

• Вариант 1: Redis + алгоритм «протекающего ведра».
• Вариант 2: счётчики в памяти (теряются при рестарте).
• Вариант 3: включить rate-limit в edge-прокси одной строкой конфига.
  Если последнее покрывает требования — выбирайте его.

Развивайте продукт, начиная с минимума и усложняя только по новым требованиям. Это YAGNI как высший принцип.

Возражения

1. Слякоть из костылей
   Костыль не прост — он добавляет сложности. Настоящее простое решение требует понимания всей системы и часто сложнее придумать.

2. Что такое «просто»?
   Простота — это минимум сущностей, минимум переходов, минимум новых инструментов. Она не всегда очевидна и требует инженерной работы.

3. Масштабирование
   Простое не значит «только сейчас». Unix-сокеты, CGI, файлы — примитивы, на которых построены крупные системы. Если завтра потребуется масштаб, выясните новые факты и добавьте минимально необходимое.

Делайте самое простое, что только может работать — и будете удивлены, как далеко это вас заведёт.

• Участники сходятся в том, что «делай самое простое, что может работать» — полезная эвристика, но не универсальный закон.
• Опытные разработчики подчеркивают: простота ≠ легкость; требует глубокого понимания задачи и контекста.
• На больших системах «простое» быстро ломается из-за edge-case’ов и масштаба, поэтому часто приходится усложнять.
• Частая ошибка — проектировать «на вырост»: реакт, k8s и прочее для сайта из трёх страниц, лишь бы «в портфолио».
• Самый практичный совет: фиксируй реальные требования здесь и сейчас и строй под них, а не под гипотетическое будущее.