Как реальные деньги автоматически долетают до целей Architector

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

Приближение вместо ложной точности

Первое решение, которое пришлось принять осознанно: считать выручку по валовому обороту, без вычета издержек — потому что учёта издержек нигде в системе на тот момент попросту не было. Можно было бы отложить всю задачу до появления полноценного учёта расходов, но это оставило бы цели без данных на неопределённый срок. Выбрали честное приближение с явной пометкой, что это приближение, а не тихую полуправду, выдаваемую за точную цифру.

Общий журнал вместо жёсткой привязки к одному источнику

Второе решение касалось архитектуры, а не просто способа считать. Можно было жёстко привязать цели к конкретной платёжной системе — раз сейчас деньги идут через неё, зачем усложнять. Но у портфеля уже есть и другие потенциальные источники дохода — торговые боты, будущие продукты — и жёсткая привязка к одному means означала бы переписывать интеграцию заново при каждом новом источнике. Вместо этого завели общий append-only журнал: файл, куда любой источник дохода может дописывать свои записи в одном и том же формате, независимо от того, как устроено его собственное внутреннее хранилище. Новый источник дохода в будущем не потребует менять существующий код — только научить его писать в тот же журнал.

Синхронизация, которая не трогает платёжный поток

Сам процесс синхронизации построен по read-only принципу: один скрипт сверяет подтверждённые заказы из основной базы с журналом, не вмешиваясь в сам процесс подтверждения оплаты. Разделение чтения и записи здесь не формальность, а конкретная защита: баг в скрипте синхронизации метрик физически не может сломать логику подтверждения реальных платежей, потому что у него просто нет доступа её менять. Второй скрипт считает сумму за текущий календарный месяц — цели заданы как повторяющиеся ежемесячные показатели, а не как накопительный итог с начала времён, и это тоже осознанный выбор: накопительный итог со временем теряет связь с текущей формой бизнеса, а помесячный показатель честно отражает, что происходит прямо сейчас — и записывает результат в файл целей, вместе с честной пометкой о том, что цифра приближённая по валовому обороту, а не чистая прибыль.

Проверка на реальном автоматическом цикле, а не только вручную

Оба скрипта подключили к уже существующему расписанию обновления дашборда Architector, которое и так работает каждые пять минут — новых отдельных таймеров заводить не пришлось, а значит и не появилось нового места, за которым нужно отдельно следить, не забудет ли оно когда-нибудь запуститься. Но подключить к расписанию и убедиться, что оно реально работает без ручного запуска — разные вещи. Проверили именно на живом автоматическом цикле, не вызывая скрипты руками: система сама пересчитала текущее значение и обновила данные, которые видит дашборд, без какого-либо вмешательства в момент проверки. Заодно почистили устаревшие пометки в файле целей и общем обзоре портфеля — фразы вроде “обновляется вручную” и “денег пока нигде нет”, которые остались от более раннего состояния системы и к этому моменту были уже прямой неправдой.

Дашборд, который эти цифры в итоге показывает, разбирали отдельно — там же, где нашлись и настоящие баги интерфейса за компанию. Общий журнал доходов создан именно для того, чтобы каждый новый продукт портфеля с личным кабинетом и оплатой — как, например, PULSE — мог начать писать туда свои записи, когда до этого дойдёт очередь, не дожидаясь отдельной интеграции под каждый конкретный источник денег.