Hyperion started as a set of Rust microservices - a deliberate exercise in distributed system design, not a product.

That shape was fine for learning. It let me experiment with observability, tracing, and the other quirks of a distributed ecosystem. But the operational cost (Kafka wiring, per-service deploys, duplicated auth/DB-pool code) wasn't worth it once the goal changed to something real and maintainable long-term.

So I moved everything into one Cargo workspace: one deployable per app, and a shared base - auth, sessions, DB pool, email, AI - written once instead of copied per service. The boundaries between domain crates are enforced by the compiler rather than by convention: a crate can only reach what it declares in its own [dependencies], and Cargo rejects a dependency cycle outright. An import that would violate the architecture fails the build.

Moving to a monorepo didn't mean giving up modularity - it's still the whole point. Domain crates stay decoupled from each other, so any of them could be pulled back out into its own service later if a real scaling need shows up.

The docs live under the same rule. A Next.js app renders the crate and architecture docs (through the same diagram pipeline used here) as one browsable book, versioned with the code it describes - so a crate rename breaks the doc build instead of quietly rotting in a wiki.