Building Java–Rust Microservices with TeaQL: Models, Events, and Audit Intent
· 14 min read
The Architecture We Actually Want
Java remains a strong choice for workflow-heavy services such as merchant onboarding, KYC, approvals, accounting, and integration with an established enterprise platform. Rust is attractive for customer-facing services where resource use, predictable latency, and fast process startup matter.
Using both languages does not mean that two services should share one database or one persistence model. That would weaken their bounded contexts. The goal is more precise:
- each service owns its model, database, and deployment lifecycle;
- reviewed metadata generates the domain API for the language used by that service;
- both stacks follow the same query-intent and mutation-audit conventions;
- communication happens through an explicit, versioned integration contract.
We built a runnable Java–Rust payment reference project to test that design instead of treating it as an architecture diagram.