Архитектура бэкенда
Собираем воедино: тест на припоминание
Припоминание сильнее перечитывания. На каждый промпт восстанови полный ответ по всему треку из памяти, прежде чем открыть модельный ответ — усилие по стягиванию связей обратно и закрепляет синтез.
Восстанови хребет юнита, не подглядывая: почему композиция не равна сложению, как вкладывается timeout budget, что делает каскад метастабильным, почему goodput — цель под overload, как RED и перцентили делают систему видимой и почему readiness — это чек-лист.
- 01Почему «композиция не равна сложению» — ядро backend-трека, и где живут самые тяжёлые баги?
- 02Проведи один запрос POST /payments вниз по стеку, назови страж на каждом слое и объясни, почему timeout budget должен вкладываться.
- 03Проведи канонический latency-каскад звено за звеном и объясни, почему путь запроса и путь shutdown — один и тот же граф.
- 04Что такое метастабильность, почему починка исходной причины её не лечит и что надо делать вместо этого?
- 05Под overload, почему отклонение запросов — корректное поведение, и чем goodput отличается от throughput?
- 06Что измеряет RED, почему надо смотреть перцентили, а не среднее, и что делает readiness-чек-лист экстернализованной экспертизой, а не бюрократией?
Если ты смог восстановить каждый ответ из памяти, ты держишь хребет трека: композиция не равна сложению, поэтому корректные части складываются в некорректное целое; timeout budget вкладывается вниз по стеку, чтобы самое внутреннее медленное упало первым; каскад уходит в метастабильность и ломается на петле обратной связи, а не на причине; goodput, а не throughput, — цель под overload, защищаемая намеренным сбросом; RED и хвост p99 делают составную систему видимой; и readiness — это калиброванный по blast radius чек-лист, имеющий смысл лишь для того, кто понимает каждый перечисленный гейт.