Архитектура бэкенда
Жизненный цикл запроса: тест на воспроизведение
Воспроизведение лучше перечитывания. Для каждого промпта скажи или запиши полный ответ по памяти, прежде чем открыть эталон — усилие реконструкции механизма и закрепляет его.
Реконструируй хребет юнита не подглядывая: семь остановок, две очереди ядра, почему порядок middleware — граница безопасности, механизм backpressure, keep-alive и как таймауты должны композироваться в бюджет.
- 01Назови семь остановок жизненного цикла запроса по порядку и один сбой на каждой.
- 02Какие две очереди ядра стоят за listen()-сокетом, что ограничивает каждую и почему somaxconn = 128 — production-ловушка?
- 03Почему порядок регистрации middleware — граница безопасности и каково правило порядка?
- 04Проследи послойно, как медленный клиент вызывает серверный OOM при стриминговом ответе.
- 05Что стоит сериализация запросу и почему статус-код — контракт, а не декорация?
- 06Что оптимизирует keep-alive и почему per-hop таймауты должны композироваться в пробрасываемый deadline?
Если ты смог реконструировать каждый ответ по памяти — ты держишь хребет юнита: семь остановок, чьи задержки суммируются плюс очереди; две очереди ядра, где somaxconn молча обрезает глубину accept; порядок middleware как граница безопасности; backpressure как userland-поверхность TCP flow control, дающая OOM при игнорировании; сериализация как реальный синхронный CPU и статус-код как контракт; и таймауты, которые должны композироваться в пробрасываемый deadline, ведь хвост fan-out, а не среднее, задаёт воспринимаемую пользователем задержку.