Архитектура бэкенда
Собираем воедино: тест с выбором ответа
Шесть вопросов, которые разом проходят поперёк всего backend-трека. Ни один не проверяет один механизм в изоляции — каждый сводит два-три из них на одном запросе под одной нагрузкой и просит прочитать взаимодействие так, как ты делал бы это в реальном инциденте.
Убедись, что рассуждаешь о семи механизмах как об одной составной системе: как корректная часть становится плохим входом для другой, как timeout budget прошивает стек, почему goodput важнее throughput и почему readiness проверяют, а не чувствуют.
Каждый из семи backend-механизмов проходит свои тесты, но самые тяжёлые инциденты команды берутся из мест, которые ни один механизм по отдельности не объясняет. Каков диагноз капстоуна?
p99 платёжного провайдера растёт с 40 мс до 4 с — без ошибок, просто медленные ответы. Через минуты медленными становятся даже эндпоинты, которые провайдер не вызывают. Чьё корректное поведение распространило сбой и через что?
У обработчика POST /payments общий бюджет 3 секунды, заданный в middleware, но downstream-вызов провайдера, acquire из pool и запись в БД несут каждый свой таймаут в 3 секунды. Почему это неверно, хотя каждый таймаут по отдельности выглядит разумно?
Во время каскада медленный провайдер полностью восстановился — задержка вернулась к 40 мс — но сервис остаётся в коллапсе. О чём это говорит и каков правильный ответ?
Сервис прошёл точку насыщения — спрос превышает ёмкость — и сейчас принимает и ставит в очередь каждый запрос. Почему добавление быстрого load shedding (503 с Retry-After на краю) увеличивает число хорошо обслуженных пользователей?
Readiness-ревью сложного нового платёжного сервиса возвращает «все восемь гейтов полностью зелёные, без оговорок». Почему senior-ревьюер скорее скептичен, чем успокоен?
Сквозная линия трека — одно утверждение: композиция не равна сложению. Корректный pool, опустошающийся под медленным downstream, становится плохим входом для breaker; корректный retry становится штормом; корректный drain гонится со застрявшей in-flight задачей. Timeout budget должен вкладываться вниз по стеку, чтобы самое внутреннее медленное упало первым; под overload ты защищаешь goodput, сбрасывая лишнее намеренно; управлять можно лишь тем, что видишь на хвосте p99, а не на среднем; и readiness — это чек-лист, калиброванный по blast radius, а не чувство. Senior-работа в backend — читать граф взаимодействий до того, как он каскадирует.