A polyglot stack is usually an accident — the residue of whoever was hired when. Ours is a decision, and the decision is defensible only because of where we put the boundaries.
The allocation
- Java, in a modular monolith — the core domain. Chosen for the thing it is genuinely best at: making a large body of business rules refactorable years later by people who did not write it.
- Python, as a separate service — AI orchestration. This is where the ecosystem lives, and it is also the fastest-moving, most vendor-volatile part of the system. Isolating it means the churn has a blast radius.
- TypeScript — the surface. One language across web and any future client, sharing types with the API contract.
- SQL, with versioned migrations — the substrate. Schema changes are reviewed artefacts, not side effects of an ORM.
Why this is not four teams’ worth of overhead
Because only one of these owns the domain. The Python service orchestrates inference; it does not hold business rules. The TypeScript surface renders and collects; it does not decide. The domain lives in exactly one place, in one language, and everything else is a surface onto it or a provider behind it.
The failure mode of polyglot systems is not the number of languages. It is business logic quietly accumulating in three of them, so that answering “what are the rules?” requires reading all three. That is the thing the boundary discipline exists to prevent.
The connection to ownership
Choosing the right language per layer is only possible if you own the layers. A stack assembled around a single vendor’s managed runtime tends to converge on whatever that vendor supports well — which is a technical decision made by someone else’s product roadmap.
Ownership is the precondition for intelligence. That applies to language choice as much as to anything else: a system you cannot reshape per layer is a system that can only be as good as its least suitable default.
Own every layer.