Go + TypeScript Monolith: The Unlikely Pair Powering TormentNexus's AI Backend

Discover why TormentNexus's AI backend is built as a modular monolith, not a microservices constellation. We explore the surprising synergy of a Go and TypeScript polyglot architecture, delivering scale with simplicity through 35+ internal packages.

The Microservices Siren Song: Why We Didn't Take the Bait

When scaling our AI inference and orchestration platform, the default industry playbook pointed toward microservices. The promise of independent scaling, technology autonomy, and team ownership is alluring. However, for our specific workload—a tightly coupled system where authentication, request routing, ML model orchestration, and real-time logging must function as a single, coherent unit—the operational overhead became a disqualifying factor. Instead, we made a deliberate engineering choice: a modular monolith.

This isn't a monolith of the past—a tangled, untestable blob. Our architecture is a single, deployable unit composed of over 35 well-defined internal packages, each with strict interfaces. The benefit? We achieve microservice-like separation of concerns with the deployment simplicity of a single binary. There's no network hop between our `auth` and `orchestrator` packages, just a direct function call, eliminating latency and the complexities of distributed tracing for internal logic. We get the developer experience of working on a single codebase while maintaining the discipline to keep domains isolated.

Go & TypeScript: A Strategic Polyglot Architecture

Choosing two languages for a monolith seems counterintuitive. Why add complexity? Because each language is a specialist tool deployed where it excels. We define our system as a Go TypeScript monolith, leveraging each for its core strengths.

Go (Golang) forms the performant, concurrent backbone. It handles our high-throughput API gateway, manages thousands of persistent WebSocket connections for real-time logs, and executes the CPU-bound orchestration logic that sequences calls to our ML models. Go's strong concurrency primitives (goroutines, channels) and simple deployment model (a single static binary) are non-negotiable for our backend core. It's the reliable engine.

TypeScript, running in Node.js, is the connective tissue for developer ergonomics and frontend integration. It owns the server-side rendering layer, the admin dashboard logic, and the internal tooling that interfaces with our GraphQL schema. Its rich ecosystem, superior JSON handling, and shared type definitions (via packages like `ts-node` and `tsx`) allow us to co-locate frontend and certain backend logic, dramatically speeding up feature development for UI-centric components. It's the user-facing intelligence.

Anatomy of 35+ Packages: Our Internal Modularity

Our repository is structured to enforce boundaries. Each of our 35+ packages has a single responsibility, public API surface, and dedicated test suite. This structure is key to making our polyglot monolith work. Below is a simplified view of our package dependency graph in our `go.mod` and `package.json` files.

// go.mod (simplified)
module github.com/tormentnexus/core

require (
    github.com/tormentnexus/auth v0.1.0       // Auth & Session Management
    github.com/tormentnexus/orchestrator v0.1.0 // AI Workflow Engine
    github.com/tormentnexus/logging v0.1.0     // Structured Logging
    github.com/tormentnexus/infrastructure v0.1.0 // DB Clients (Postgres, Redis)
    // ... 20+ more internal packages
)

// packages/infrastructure/ts-client/package.json (simplified)
{
  "name": "@tormentnexus/ts-infrastructure",
  "dependencies": {
    "@tormentnexus/shared-types": "1.0.0", // Shared TS/Go types via JSON schemas
    "next": "^14.0.0",
    "graphql-request": "^6.0.0"
  }
}

For example, a request flows through: `auth` (Go) -> `orchestrator` (Go) -> a call to `model-service` (Go gRPC client) -> response enriched and logged via `logging` (Go) -> finally rendered via a Next.js page (`ts-infrastructure` package). The clean interfaces allow us to test `orchestrator` by mocking `model-service` without any network calls.

Powering the AI Backend with Co-located Modules

In an AI backend, performance and iteration speed are everything. Our monolith lets ML engineers deploy new model adapters (like for Stable Diffusion XL or Llama 3) as new Go packages without coordinating a separate microservice release. The `orchestrator` package can then discover and use these adapters instantly after a single deployment of our main binary.

We use a dedicated `models` package that abstracts the specifics of each AI provider (OpenAI, Anthropic, local vLLM instances). This package handles prompt templating, response parsing, and retry logic. Because it's part of our monolith, it has direct access to the same connection pools and configuration as the `orchestrator`, removing boilerplate and ensuring consistency.

Modular Monolith vs. Microservices: The TormentNexus Calculus

The trade-offs are clear and deliberate. We trade the infinite horizontal scalability of each individual service in a microservices setup for the absolute performance, simplicity, and debuggability of a unified system. For our current scale (handling ~10,000 requests per second with p99 latency under 50ms), this trade-off is overwhelmingly positive. Debugging an issue is a matter of checking stack traces, not correlating logs across a dozen Kubernetes pods. Deployment is a `git push` to our CI/CD pipeline, resulting in a single, validated artifact.

Our polyglot architecture within this monolith gives us the flexibility to choose the right tool without the operational cost of a service mesh. We get the Go performance we need for core AI routing and the TypeScript developer velocity for everything touching the web layer. It's a unified architecture that acknowledges different parts of the same problem require different solutions.

Experience a backend architecture designed for clarity and performance. Learn more about our engineering choices and the TormentNexus platform at https://tormentnexus.site.

---

Originally published at tormentnexus.site