Redesigning ERP Systems with Distributed Micro‑services Architecture

ERP Pain Points

The author, after four years of developing large‑scale ERP systems for e‑commerce and jewelry businesses, explains that conventional monolithic ERP architectures—built with .Net or Java, a single process, and one SQL Server/MySQL database—initially perform well but degrade as order volume and reporting demands grow.

Attempts to improve performance by isolating the database or adding indexes help only marginally, because many list and export queries still become slow due to complex joins across multiple tables and high data volume.

Typical ERP workloads involve low concurrency but high business complexity, with many‑table joins, strict transactional and consistency requirements, making it difficult to apply generic high‑concurrency solutions used by internet companies.

Emerging Solution

The proposed direction is to abandon the “one‑size‑all” monolith and adopt a distributed, service‑oriented architecture. Each functional area—order management, product management, procurement, warehouse, logistics, finance—is extracted into its own subsystem with its own database and can be developed by separate teams using different technologies.

Advantages of the New Architecture

1. **Performance**: Multiple database instances can be added for load balancing; write‑side databases are isolated per subsystem, avoiding the limitations of traditional read‑write splitting in ERP scenarios.

2. **Ease of Updates**: Subsystems are deployed as backend micro‑services behind a thin web front‑end, allowing independent upgrades without restarting the whole system or forcing users to re‑login.

Overall System Design

Physical deployment view (illustrated in the original article).

Detailed Design – Splitting the Application Layer

Micro‑services expose RESTful or Dubbo interfaces; the web front‑end acts only as a presentation layer, delegating business logic to the services. Dubbo (or similar RPC frameworks) provides protocol support, service registration (e.g., Zookeeper), load balancing, and graceful scaling.

Splitting the Data Layer

Database sharding is achieved by giving each subsystem its own database. For cross‑subsystem data (e.g., displaying material inventory that requires material, category, and warehouse information), the consuming service calls the provider service to fetch related data and assembles the final result, replacing traditional SQL joins.

Although this introduces extra network calls and may be slower for small datasets, it prevents a single database from becoming a performance bottleneck as data grows.

Further scaling can be done by adding read‑write separation, caching, or additional sub‑subsystems based on load.

Reporting System

Complex reports that involve many tables can be offloaded to a dedicated reporting subsystem built on a data‑warehouse style schema with denormalized tables and extensive indexing. Data synchronization can be performed via scheduled jobs or real‑time triggers.

Distributed Transactions

To maintain consistency across services, the article suggests using local transactions within each service combined with a message‑queue (e.g., ActiveMQ) for eventual consistency. If a downstream service fails, the message is retained for retry, and failures are logged for manual compensation.

This pattern achieves data integrity without requiring heavyweight distributed transaction protocols.

Conclusion

The author shares personal experience, encourages adopting micro‑service and distributed designs for ERP systems, and invites feedback to improve future articles.