Почему «асинхронность» — не серебряная пуля, или как я перестал плодить горутины и вернулся к тредпулам

Тема набила оскомину, но каждый второй джун с горящими глазами лепит async/await и горутины куда ни попадя, а потом удивляется, почему у него прод падает на первом же всплеске нагрузки. Очередная итерация «чистой архитектуры» превращается в винегрет из контекстов, каналов и дебагов, где невозможно уследить за потоком данных. Я за последние полгода дважды переписывал сервис на Go: сначала наваял «правильно» — каналы, горутины на каждый чих, потом понял, что 90% времени теряется на блокировках БД и внешних API, а не на CPU. Вернул классический тредпул с очередью — стало предсказуемее, метрик меньше, а нагрузка легла ровно. Проблема не в инструменте, а в том, что мы забываем: асинхронность решает конкретную задачу, а не все проблемы мира. Кто сталкивался с тем, что «асинхронная» система начинает жрать память из-за неявных гонок или переполненных буферов? Как вы решаете, когда горутины/таски реально оправданы, а когда это — оверинжиниринг ради красивого резюме? Или я один такой «динозавр», который предпочитает жёсткий тредпул и пул коннектов вместо магии рантайма?