Vestry
A distributed Telegram-facing system: four Rust backend services talking over gRPC, with agent-adjacent processing behind the protocol boundary.
- Ownership
- Commissioned work, built with and for a partner. Red Sentra keeps an ongoing support role. The partner and the commercial terms stay private.
- Availability
- Private product. Source is private.
- Stack
- Rust / MTProto / gRPC / Protocol Buffers
The problem
Working against Telegram at the protocol level is unforgiving. Sessions are stateful, limits are enforced for real, and the client is long-lived. Anything that treats it like an ordinary request-response integration falls over quickly and in ways that are hard to diagnose.
The system
Four Rust backend services with separate responsibilities, communicating over gRPC with Protocol Buffers as the contract. The MTProto-facing layer is isolated from everything else, so protocol behaviour, and protocol failure, does not leak into the services doing the actual product work.
My role
Backend and systems engineering: service decomposition, the gRPC contracts between the services, the MTProto integration boundary, and how the system behaves when one part of it is down.
The hard part
Long-lived stateful connections do not fit a stateless service model. Deciding where state was allowed to live, and how a restart of any single service could be survivable, shaped most of the architecture.
Architecture decisions
- Protocol isolation. Everything MTProto-specific sits behind one boundary, so the rest of the system speaks in domain terms and can be tested without touching Telegram at all.
- Schema-first contracts. Protocol Buffers between services make a breaking change visible at build time instead of at three in the morning.
- Four services, not one. The split followed failure domains and scaling needs rather than tidiness, so the noisy parts can be restarted without taking the quiet ones down with them.
Where it stands
In production, with Red Sentra continuing to support it.