Skip to main content
Architecture9 min read

Архитектурное решение, которое никто не записывает

Мы тратим недели на выбор между Kafka и RabbitMQ, но никогда не документируем, почему. ADR занимают 15 минут и экономят месяцы разговоров «почему мы это сделали?».

Part ofProduct Systems->
By Jason TeixeiraDecember 20, 2025
ArchitectureDocumentationADRDecision MakingBest Practices
Share:
On this page

Шесть месяцев назад я выбрал Supabase вместо Firebase для Nexural. У меня были веские причины — PostgreSQL, безопасность на уровне строк, возможность самостоятельного хостинга. Но я чуть не забыл эти причины. Единственное, что спасло меня от повторной оценки того же решения (и потери недели), — это markdown-файл, который я написал за 15 минут.

Проблема

В каждой инженерной команде бывает такой разговор:

«Почему мы используем RabbitMQ вместо Kafka?» «Кажется, Дейв выбрал его. Дейв уволился 8 месяцев назад.» «...» «Может, перейдём на Kafka?»

И вот вы тратите спринт на переоценку решения, которое уже было оценено. Институциональное знание вышло за дверь.

Записи архитектурных решений (ADRs)

ADR — это короткий документ, фиксирующий значимое решение. Мои предельно просты:

\\

Reader route

article -> proof -> offer

ReadClusterProofScope

cluster

Product Systems

intent

Architecture

route

next step

What to do with this

Turn the note into a build path.

If this topic maps to a real business problem, keep reading the cluster, study the academy path, or route the work into a scoped engagement.

Jason Teixeira
Written by
Jason Teixeira
Founder, Sage Ideas Studio · Principal Engineer
livebuild 5d6c8652026-08-05 06:00Z
// solo studio// no analytics resold// every commit human-reviewed