Scope, maturity and exit¶
MIC is a cross-cutting foundation for Python and Node.js, not a complete application platform. This page makes three adoption facts explicit: what both implementations share, the evidence available for each one, and what must be replaced if a service leaves MIC.
Shared scope¶
Both implementations provide independent building blocks that services assemble explicitly:
- static or governed contracts and canonical HTTP envelopes;
- framework-neutral domain routes and HTTP adapters;
- scope-bound service authentication, an HTTP client, and domain errors;
- organization-scoped persistence, order-aware outbox, queues, cache, and locks;
- periodic work with checkpoints, execution tracking, and silence detection;
- optional logs, metrics, and OpenTelemetry tracing;
- test tooling and a service generator.
The domain, data schema, migrations, and deployment remain owned by the service. MIC does not hide runtime libraries: Pydantic, SQLModel, SQLAlchemy, FastAPI, and Litestar stay visible in Python; TypeScript schemas, storage, and Node HTTP, Express, Fastify, Hono, or NestJS stay directly accessible in Node.js.
Evidence by runtime¶
The two implementations do not claim the same maturity level.
Python¶
Available evidence. Use by real, integration-heavy services covering HTTP, authentication, events, outbox delivery, observability, and operational storage.
Limit. This experience does not prove the behavior of a complex bitemporal aggregate, a runtime-editable metamodel, or billions of facts.
Node.js¶
Available evidence. Native tests, npm archive verification, installation of published packages in an empty project, and execution of the generated service.
Limit. These checks are not yet production feedback equivalent to the Python implementation.
This evidence validates cross-cutting plumbing within its stated boundaries. It does not replace product-owned validation of business invariants, indexes, partitions, or performance. An implemented capability is not described as proven at scale without matching production measurements.
Currently out of scope¶
The stable MIC API does not provide:
- the trigger or process supervisor for periodic work: infrastructure calls the Python or Node.js runner and enforces hard termination;
- a distributed schema source of truth or invalidation bus: the registry receives a loader and the application broadcasts changes;
- a database security policy: tenant-scoped storage protects the injected view, but cannot stop code that was also given the raw store;
- exactly-once delivery, global ordering, or a long-term archive: per-aggregate ordering is opt-in and replay reads a separate archive;
- a deployment platform, observability backend, or retention policy;
- service domain rules, migrations, or physical data models.
These limits are neither forbidden designs nor implicit promises. The Python
architecture documentation details
governed contracts,
periodic work,
organization isolation, the
SQL escape hatch, and
outbox guarantees. The
mic-node repository
documents the TypeScript contracts and their adapters.
Adoption constraints¶
The runtime choice is part of the adoption decision.
Python¶
The distributions target Python 3.14. The base image and target environment must provide this version.
Node.js¶
The packages require Node.js 24 or later. The production runtime and CI
toolchain must satisfy engines.node. The @mic-struct/* packages are
published on the public npm registry; installing them requires no token or
MIC-specific registry.
MIC does not promise compatibility with versions older than those declared by its packages. For software deployed into third-party environments, verify these constraints before migration.
How to leave MIC¶
Exit is incremental and module by module. There is no proprietary data format to convert, and the service keeps its data, domain contracts, and deployment configuration.
Leaving the Python implementation¶
| What the service already owns | What must be replaced |
|---|---|
| Models, schemas, and domain rules | Uses of StrictSchema, SchemaRegistry, or envelope helpers |
| Tables, migrations, and native SQL | The storage lifecycle and TenantScopedRelationalStore |
| Framework-neutral domain handlers | The HttpRouteSpec adapter for FastAPI or Litestar |
| Event topics, payloads, and identifiers | MIC outbox storage, dispatch, and replay |
| CronJob or systemd triggers | mic.scheduling state, checkpoints, and metrics |
| Deployment configuration | Adopted authentication, client, and observability helpers |
Leaving the Node.js implementation¶
| What the service already owns | What must be replaced |
|---|---|
| Models, schemas, and domain rules | Schemas, governed registries, or envelopes imported from @mic-struct/mic-core |
| Tables, migrations, and native SQL | MIC stores and the TenantScopedRelationalStore view |
| Framework-neutral domain handlers | The adapter for Node HTTP, Express, Fastify, Hono, or NestJS |
| Event topics, payloads, and identifiers | The outbox and queue contracts from @mic-struct/mic-datastore |
| CronJob or systemd triggers | The runner, scheduling store, and their metrics |
| Deployment configuration | The corresponding @mic-struct packages |
A practical migration replaces one boundary at a time, keeps contract tests,
and verifies public responses before removing the corresponding MIC package.
Inventory mic.* imports in Python or @mic-struct/mic-* imports in Node.js;
domain code and data remain owned by the service.
Decision rule¶
Adopt MIC to share explicit cross-cutting guarantees. Do not expect MIC to choose the model, operations, or scale strategy for the product. Start with the Python quickstart or the Node.js quickstart, depending on the runtime you want to evaluate.