Гонка в денежном протоколе
Два перевода одновременно проходят проверку лимита, и остаток уходит в минус.
Для каждой денежной операции строится модель протокола. Перебор находит такую гонку за миллисекунды и показывает шаги, которые к ней ведут.
Платежи · банковские переводы · высокие нагрузки
Архитектура, в которой деньги не теряются и не списываются дважды
Я проектирую критичные системы на собственной платформе Architect OS. AI ускоряет проектирование, но ни одно его решение не попадает в проект без проверки: протоколы движения денег проверяются перебором всех состояний, контракты сервисов на совместимость, расчёт мощности считает сервер. Ошибки находятся на схеме, а не в продакшне.
- 35 / 35
- сценариев восстановления после сбоев прошли в трёх сложных проектах
- 18 / 18
- эталонных задач, включая платёжный шлюз и межбанковские переводы
- 0
- пропущенных критичных требований
Модель предлагает, решает сервер
Языковые модели ошибаются уверенно. Поэтому в Architect OS нет шага, на котором слову модели верят без проверки. Каждое предложение проходит детерминированный код, который модель не может ни обойти, ни переписать. Если ответ отклонён, модель получает точный список нарушений и присылает исправление.
- Влияниечто новое сообщение меняет в готовой схеме
- Требованиятребования, допущения, вопросы с вариантами
- Проектированиекомпоненты, решения с альтернативами, контракты, модели протоколов
- Критиканезависимый проход по нарушениям, найденным проверками
- Проверка34 правила, модели протоколов, контракты, расчёты
- Сохранениеодна атомарная ревизия или ничего
- Как ошибается AI
Пропускает гонку, двойное списание, зависший статус
Что это ловитИсполняемая модель протокола: перебор всех чередований (BFS), инварианты, сценарии восстановления после сбоя
РезультатНарушение возвращается с кратчайшей трассой. Денежный протокол без модели не пройдёт согласование:
MODEL_REQUIRED - Как ошибается AI
Предлагает несовместимый вызов между сервисами
Что это ловитСверка контрактов: поля, типы, обязательность, ключ идемпотентности у повторяемых операций
РезультатCONTRACT_INCOMPATIBLEблокирует согласование - Как ошибается AI
Ошибается в арифметике нагрузки
Что это ловитСервер вычисляет формулы, проверяет размерности, протягивает диапазоны неопределённых входов
РезультатРезультат считает сервер. Расхождение с другим расчётом —
CAPACITY_CHAIN - Как ошибается AI
Забывает последствия изменившегося факта
Что это ловитАнализ влияния по графу зависимостей; пометки «на пересмотре» ставит и снимает только сервер
РезультатПока каждый затронутый пункт не исправлен или не обоснован, сохранить проект нельзя
- Как ошибается AI
Ссылается на несуществующее или теряет связь с требованием
Что это ловитСхема данных, ссылочная целостность, двусторонняя трассировка требований
РезультатОбязательное требование без реализации и проверки не допускается к ревью
- Как ошибается AI
Придумывает факты или одобряет сам себя
Что это ловитТребование «от заказчика» должно ссылаться на реальное сообщение; модель не может одобрить проект или создать доказательство
РезультатДогадки становятся допущениями, привилегированные команды отбрасываются
Сложные системы, проверенные до разработки
Три задачи уровня реальных проектов прошли через Architect OS целиком. На втором шаге каждой условие меняется посреди работы, как это бывает в жизни. Ниже — что система спроектировала, что проверила и как пересмотрела решения. Проекты открываются целиком, только для чтения.
Одна пропущенная проверка — и бюджет перерасходован
Реальная модель протокола из эталонной задачи о корпоративных закупках: лимит филиала 3, каждый заказ резервирует 2. Уберите из проверки лимита резервы «в пути», и система найдёт перерасход, перебрав все состояния.
В модели 10 переменных и 26 действий: резерв, запрос на склад, ответы, таймауты, отмены, повторные отмены. Показан итог настоящей проверки.
Где проекты теряют деньги
Шесть ситуаций, которые обходятся дороже всего, и что система делает в каждой сама, не полагаясь на внимательность людей.
Статус «неизвестно» после таймаута
Банк или эквайер не ответил вовремя. Повтор запроса означает двойное списание, отмена — потерянные деньги.
Неизвестный исход — отдельное состояние протокола. Сценарии восстановления проверяют, что он всегда разрешается без двойного списания.
Микросервисы там, где хватит монолита
Для задачи, с которой справится один сервис, строят десяток сервисов, очередь и оркестрацию. Всё это потом годами поддерживают.
По умолчанию — модульный монолит. Распределение допускается, только когда его оправдывают требования, и решение фиксируется с альтернативами и условием пересмотра.
Несовместимые требования
«Строгая согласованность между континентами и подтверждение за 5 мс». Противоречие всплывает после месяцев работы.
Конфликт помечается и доказывается цифрами: задержка между регионами, минуты простоя в год. Выходы предлагаются вариантами одного вопроса.
Факты меняются посреди проекта
«Регулятор может подтвердить перевод через 10 минут». Половина решений тихо устаревает.
Всё, что зависело от старого факта, находится по графу и помечается к пересмотру. Сохранить проект нельзя, пока каждый пункт не закрыт.
Мощность «на глаз»
«Хватит трёх серверов». Число в тексте расходится с расчётом, запас на отказ ЦОДа никто не проверял.
Формулы считает сервер. Неопределённые входы задаются диапазонами, результат тоже выходит диапазоном, а значения, взятые из другого расчёта, не могут с ним разойтись.
Результаты на эталонном наборе
Систему оценивают два независимых судьи: машинные проверки с весами по серьёзности (критично ×5, важно ×3, мелочь ×1) и отдельная модель-рецензент, которая видит только задачу, критерии и результат. Набор из 15 задач покрывает простые системы, задачи-ловушки, противоречивые требования, денежные протоколы, пересмотр решений, медицинские данные и рост нагрузки.
Показать таблицей
93% → 100%машинные проверки с весами
6,4 → 7,9средняя оценка рецензента
403автотеста на сам механизм проверок
Ограничения, о которых стоит знать
- Проверка на модели не заменяет нагрузочный тест. В системе это разные статусы: «проверено на модели» и «измерено».
- Три задачи после доработки потеряли по баллу у рецензента — это видно на графике.
- Слабее всего пока расчёт роста нагрузки (6 из 10). После этого появилась автоматическая сверка цепочек расчётов.
Сколько стоит ошибка, найденная поздно
Ошибка проектирования, обнаруженная после начала разработки, стоит команде недель переделки. Подставьте свои значения.
Экономия на проекте—
Аудит существующей системы
Переношу архитектуру в модель и прогоняю проверки. Результат: риски по серьёзности, найденные гонки и несовместимости, план исправлений.
Архитектура нового проекта
От требований до пакета для команды: решения с альтернативами, проверенные протоколы, контракты, расчёт мощности сейчас и при росте, критерии приёмки.
Сопровождение изменений
Когда меняются условия, анализ влияния показывает, что пересмотреть, а журнал хранит, почему решения стали такими.
все проверки пройдены
Обсудим вашу систему
Расскажите о проекте или текущей архитектуре. Покажу, что найдут проверки, на ваших требованиях.