Cloudflare Workers ломают не код, а границы ответственности

Workers удобны там, где нужна лёгкая serverless-логика у края сети: редиректы, нормализация URL, заголовки, A/B-маршрутизация, токен-проверки. Но как только в воркер начинают тащить тяжёлую бизнес-логику, растёт латентность, усложняется отладка и теряется прозрачность отказов.

Главная ошибка — использовать Worker как мини-бэкенд для всего подряд. Правильнее держать в нём короткий слой управления запросом:
— проверить auth и контекст;
— быстро решить, кэшировать ответ или проксировать дальше;
— не обращаться к внешним API без крайней необходимости;
— не делать лишних преобразований тела ответа.

Если логика зависит от состояния, используйте Durable Objects или выносите её в основной сервис. Worker хорош как координатор, а не как место, где живёт вся предметная область. Иначе при росте нагрузки вы получите сложную трассировку и непредсказуемый cold path. Безопасность и скорость: находим баланс в каждой конфигурации.

Практика простая: держите воркер коротким, детерминированным и наблюдаемым. Логи, метрики ошибок и контроль кэша важнее «умного» кода. Стабильность инфраструктуры — залог масштабируемости.