Кейс по асинхронности в Django: контекст → действие → результат.

Кейс по асинхронности в Django: контекст → действие → результат.

Контекст: сначала автор пошёл по мягкому пути — гринлеты, как у SQLAlchemy. Proof-of-concept поднялся, но дальше вылезла классика: двойная поддержка sync + async, рост test matrix, усложнение всего стека. Вывод простой: если тащить две модели сразу, цена поддержки быстро съедает любой выигрыш.

Действие: подход сменили на радикальный — async-only без обратной совместимости. В лоб: заменить часть `def` на `async def`, добавить `await` по цепочке и перестроить код под один сценарий, без оглядки на старый синхронный слой.

Результат: не «ускорили всё в 2 раза», а убрали компромисс. Меньше ветвлений, меньше тестовых комбинаций, чище архитектура. Но и риск выше: ломается совместимость, а значит миграция будет дорогой.

Для WB-реальности логика такая же: если фича тянет за собой два процесса, две логики и две поддержки — это не оптимизация, а скрытый налог на команду.