В 2002 году внутри Amazon случилась штука, которая потом стала одной из причин, почему “просто интернет-магазин” превратился в гигантскую платформу

По легенде, Джефф Безос разослал по компании короткое правило (по сути — ультиматум):

Любая команда обязана отдавать свои данные и функции через интерфейс. Никаких “давай мы просто напрямую залезем в вашу базу”. Никаких “мы вам скинем файлик” и “у нас исключение”. Только через интерфейс.

Звучит скучно? Вот почему это не скучно.

До этого в больших компаниях всё обычно устроено так: • один отдел делает фичу и “тихо” читает таблицы другого, • кто-то добавил поле — и половина сервисов падает, • никто не понимает, кто за что отвечает, • скорость разработки превращается в болотце.

А “интерфейс-правило” насильно делает другое: • границы становятся чёткими (кто владеет чем), • ответственность становится конкретной (если интерфейс сломан — виновник виден), • масштабирование становится возможным (новая команда подключается по правилам, а не через дружбу).

И главное — появляется эффект, который многие недооценивают:

Когда ты заставляешь всё общаться через интерфейсы, ты случайно начинаешь строить платформу

Потому что “интерфейс” — это уже почти продукт. Его можно улучшать, измерять, версионировать, делать стабильным. А дальше появляются сервисы, “магазин сервисов”, внутренние инструменты… и в какой-то момент это выстреливает наружу.

Если совсем по-простому: они убрали хаос коммуникаций — и получили системный рост скорости.

3 вывода, которые можно забрать себе

1. Если у тебя 2+ человека в продукте — запрети “обходные пути”. То, что сегодня “быстро”, завтра — вечная боль. 2. Если хочешь стабильность — делай “один путь”, а не “сто вариантов”. Вариативность без правил = технический долг. 3. Если хочешь масштаб — сначала введи правила, потом добавляй фичи.

Иначе ты просто ускоряешь хаос.