Production architecture

После главы вы сможете собрать изученные contracts в deployment topology и объяснить failure/degradation каждого компонента.

Reference architecture

Это не обязательный набор microservices. В малой системе несколько boxes живут в одном process, но responsibilities и contracts всё равно различаются.

API boundary

API отвечает за:

• authentication/tenant resolution;
• request schema и idempotency request ID;
• sync vs async contract;
• streaming/status/cancel endpoints;
• rate/size limits;
• безопасную user-facing error semantics.

Не держите долгий run привязанным к одному HTTP connection. API может вернуть run_id, а client получать status/events/stream отдельно.

Queue и workers

Queue сглаживает spikes и позволяет retry delivery. Worker должен быть stateless относительно process memory: load run projection, acquire lease, сделать один/несколько bounded transitions, сохранить events, release.

Нужны:

• visibility timeout/lease;
• dedupe run/operation;
• dead-letter и manual tooling;
• priority/fairness per tenant;
• cancellation propagation;
• backpressure.

Queue at-least-once delivery усиливает необходимость idempotency.

Model gateway

Gateway скрывает vendor SDK и централизует:

• auth/endpoints;
• timeout/retry policy для inference;
• model aliases/routing;
• token/cost accounting;
• content/data-region policy;
• prompt/model version metadata;
• fallback/circuit breaker.

Не превращайте gateway в god service, который знает domain workflow. ModelPort остаётся малой границей runtime.

State stores

Разные данные имеют разные lifecycle:

Store	Данные	Инвариант
Event/checkpoint	Run history	Append/version/lease
Conversation	User-visible turns	Retention/access
Domain DB	Orders/money/bookings	Business atomicity
Memory	Scoped durable facts	Consent/deletion
Retrieval index	Derived chunks/vectors	Provenance/version
Telemetry	Spans/logs/metrics	Redaction/retention
Eval dataset	Curated cases/labels	Version/leakage/access

Одна vector DB «для всей памяти» не заменяет эти semantics.

Tool plane и policy plane

Registry разрешает fully qualified/versioned capability. Policy использует trusted identity, actual arguments, effect class и current rule revision. Domain service финально обеспечивает invariant.

Для remote integrations может использоваться MCP/gateway, но transport не должен расширять authority.

Multitenancy

Tenant boundary проходит через весь call chain:

• resolution на API;
• queue partition/fairness;
• state/memory/retrieval keys;
• scoped credentials;
• tool/domain queries;
• telemetry redaction;
• eval dataset access.

Tenant ID от модели игнорируется. Он приходит из authenticated execution context.

Budgets и admission control

До старта оцените допустимые:

• concurrent runs;
• max steps/tool calls;
• token/cost;
• wall time/deadline;
• external writes;
• retrieval size;
• approval wait/expiry.

Admission control может отправить request в очередь, выбрать cheaper model/workflow или отказать до расхода ресурсов.

Model routing

Варианты:

• один стабильный model baseline;
• rule-based routing по risk/latency;
• small classifier с abstain;
• cascade: дешёвый model → evaluator → escalation;
• ensemble/multiple trials только там, где eval доказывает benefit.

Routing — часть системы и должен оцениваться вместе с harness. Лучший model score не гарантирует лучший end-to-end outcome при другом tool/context interface.

Graceful degradation

Сбой	Degradation
Model provider unavailable	Fixed workflow/queue/human handoff
Retrieval down	Domain tools + честно ограниченный ответ
Tool upstream down	Retry/reconcile, не hallucinated success
Policy unavailable	Fail closed для writes, возможно reads
Telemetry down	Продолжить по policy, буферизовать; recovery не ломается
Eval platform down	Не блокировать active user run; блокировать risky release
Memory unavailable	Продолжить без personalization, не cross-tenant fallback

Degradation заранее проектируется и тестируется. «Пусть модель импровизирует» — не fallback для unavailable ledger.

Release lifecycle

Версионируйте как единый system bundle:

• model/parameters;
• instructions/prompts;
• tool schemas/descriptions;
• workflow/policy;
• retrieval index/corpus;
• grader versions.

Путь: offline eval → shadow → canary → monitored rollout → rollback. Score сравнивается с latency/cost/safety, а не отдельно.

Multi-agent placement

Multi-agent — optional orchestration внутри worker plane. Каждый agent получает отдельный context/capability budget, а parent проверяет handoff. Нельзя позволять child расширять credentials или писать в общий state без concurrency contract.

Добавляйте только после baseline одного agent/workflow и измеримого выигрыша на tasks, где independent parallel exploration или security separation действительно нужны.

Варианты deployment

Вариант	Выигрыш	Цена	Когда плохой выбор
Synchronous monolith	Быстрый старт	Нет long-run resilience	Approval/voice/long tools
Async worker + DB	Хороший middle ground	Custom timers/leases	Очень сложные sagas
Durable workflow platform	Rich lifecycle	Platform complexity	Малый traffic/prototype
Managed agent platform	Быстро/hosted tools	Portability/control	Special compliance/contracts

Helios и реальные аналоги

Helios объединяет marketplace, logistics, wallet и regulated support, но runtime core не знает lore. Domain adapters меняются; contracts model/tool/policy/event/eval остаются. Такой portfolio-проект показывает работодателю architecture transferability к fintech, marketplace, travel и telehealth.

Лаборатория

npm run demo:course
npm run test:course

Возьмите diagram и для каждого edge запишите timeout, identity, idempotency и observable outcome. Затем удалите один box: какие responsibilities нужно перенести, чтобы инварианты сохранились?

Self-check

• Как API продолжает run после disconnect?
• Где lease предотвращает concurrent worker?
• Какой store authoritative для каждого типа данных?
• Что происходит при policy/model/retrieval outage?
• Как tenant identity доходит до DB?
• Какие versions образуют release bundle?
• Есть ли доказательство, что multi-agent сложность окупается?