Why Microservices for an ERP?
When we set out to build our ERP platform, we faced a fundamental architectural decision: monolith or microservices? For an ERP serving multiple tenants with modules spanning CRM, Accounting, Inventory, HR, and more, microservices was the clear choice.
The Architecture
Our polyrepo approach uses 41 repositories: 16 backend Laravel services, 16 Vue 3 microfrontends, and shared packages. Each service owns its domain, its database schema, and its API surface. Inter-service communication happens through NATS JetStream — giving us guaranteed delivery, replay capability, and decoupled services.
Module Federation with Rsbuild
On the frontend, each module is a standalone Vue 3 application that exposes components via Module Federation. The shell application dynamically loads modules at runtime, meaning each team can deploy their frontend independently.
Key Learnings
- Event-driven architectures require careful schema versioning
- Per-tenant database isolation adds complexity but is worth it for enterprise clients
- Shared packages (auth SDK, UI components) must have strict versioning
- Kubernetes makes service orchestration manageable at scale