❓ Why TigerBeetle-style architecture over microservices?

[copyleftdev]

This project chose a TigerBeetle-inspired single-binary architecture over the more common microservices approach.

The TigerBeetle Philosophy

• Single binary — No Kubernetes, no service mesh, no external databases
• Zero dependencies — Custom storage (WAL + LSM), custom networking
• Deterministic — Same input = same output, always
• Raft consensus — Built-in replication and fault tolerance

Trade-offs

Microservices	Single Binary
Independent scaling	Vertical scaling
Polyglot	Single language (Rust)
Complex deployment	Simple deployment
Network latency	In-process calls
Eventual consistency	Strong consistency
Many failure modes	Fewer failure modes

Questions

1. When would you choose single-binary over microservices?
2. What domains benefit most from strong consistency?
3. Have you built TigerBeetle-style systems before?

Curious to hear different perspectives! 🏗️

[anntnzrb]

The mox_eda project chose TigerBeetle-style architecture for correctness guarantees and operational simplicity - trading microservices' independent scaling for deterministic behavior, strong consistency, and zero external dependencies. Key technical benefits: in-process calls eliminate network latency, custom WAL+LSM storage provides better performance than external databases, and deterministic simulation testing (RFC-0005) enables fault injection without complex distributed test infrastructure. The tradeoff analysis in discussion #101 shows this fits event-sourced systems requiring strong consistency where operational complexity of service meshes/Kubernetes outweighs polyglot flexibility. Implementation tracked across 82 GitHub issues with RFCs defining acceptance criteria (docs/rfcs/RFC-0001-architecture-overview.md:1-50 details the zero-dependency approach).