Building ERP on Microservices: What I Learned

Two years ago, we decided to rebuild an ERP system using microservices. Docker. Kubernetes. The whole stack. It was 2015. Microservices were the future. Containers were going to solve everything. Every tech conference was full of this story.

We were not alone in this decision. Half the tech industry made the same choice.

I'm standing here in August 2017 with something to tell you: we built it correctly, and it was still too complex.

The problem statement was reasonable: a traditional ERP is monolithic. It's brittle. You can't scale the procurement module independently from sales. You can't deploy an update to accounting without redeploying manufacturing. You can't have different teams owning different parts of the system. Microservices solve all of that.

And they do. Theoretically.

The reality is that monoliths are hard. Microservices are harder—just in different ways.

The Problems We Didn't Anticipate

We started with a clean architecture. Procurement service. Sales service. Accounting service. Finance service. Manufacturing service. Each service had its own database. Each service had its own CI/CD pipeline. Each service could be deployed independently.

Beautiful architecture.

Then we realized that in an ERP, everything connects to everything.

A sales order creates a demand. The demand triggers procurement. Procurement creates a purchase order. The purchase order needs to sync back to accounting. Accounting needs real-time visibility. Which service owns that responsibility? Who owns data consistency?

We built event streams. Kafka in the middle. Services publish events. Other services subscribe. Now we have asynchronous cross-service communication. Great.

Until an event gets lost. Or arrives out of order. Or two services disagree about the state of an order. Now you need distributed transaction handling. Now you need saga patterns. Now you need monitoring on top of monitoring because you can't actually see what's happening end-to-end anymore.

We spent six months on consistency alone.

Then there's operational complexity. With a monolith, you deploy one thing. You restart one thing. You monitor one thing. With microservices, we have a dozen services. Each has its own dependency chain. Each has its own failure modes. We needed Kubernetes to manage it all. We got Kubernetes. We also got a 10-person DevOps team just to keep the cluster running.

The cost was staggering. Not just in infrastructure, but in development velocity. Every feature now requires coordinating across multiple services. Every deploy is a distributed system problem. Testing is a nightmare because you need a full environment with all services running and data synchronized to catch integration bugs.

A year into the project, we sat down and asked ourselves: is this worth it?

Where Microservices Actually Mattered

The honest answer was: partially.

Where microservices were genuinely useful:

We could scale the data warehouse service independently. It was CPU-intensive. Heavy analytics. We needed to scale it differently from transaction services. That worked.

We could have a dedicated team owning procurement without affecting the sales team. That mattered for large teams.

We could deploy procurement updates without touching the rest of the system. That felt good for risk management.

Where microservices created more problems than they solved:

The accounting service needs real-time visibility into all orders. That means subscribing to events from five other services. The dependencies grew complex. The testing became exponentially harder.

Reporting across the ERP became an ETL nightmare. You need a data warehouse. You need to sync data from multiple databases. You need to handle eventual consistency in reports.

Debugging production issues. A customer reports a missing order. You're checking the sales service, the procurement service, the warehouse service, the fulfillment service, the accounting service. Tracing requests across systems is painful.

We could have gotten 70% of the value with a monolith plus good architecture. We'd have clear boundaries between modules. We'd have one database we could query. We'd have eliminated the coordination overhead. We'd have ship features faster.

What We'd Do Different

If I were starting this project today, I'd build it as a modular monolith first. Clean architecture. Services in separate packages. Strict boundaries. But everything running in one process, one database.

Then, only if scaling became a real constraint, I'd break out individual services. I'd know exactly where the bottleneck is. I'd solve an actual problem instead of a theoretical one.

The microservices hype in 2017 is at peak level. Everyone's doing it. Kubernetes adoption is exploding. Docker is standard. But I'm watching teams build microservices and then spend years managing operational complexity they didn't actually need.

Microservices are not free. The operational cost is real. The mental model is harder. The testing is more complex. If you need them—if you actually have scaling challenges or truly independent teams—they're valuable. But if you're building them because it's fashionable, you're paying a price for a benefit you don't get.

For an ERP system specifically, I'd be very skeptical of full microservices. ERP systems have tight data coupling. Everything needs to be consistent. Everything needs to be auditable. Those constraints actually argue against microservices, not for them.

Build it clean. Build it modular. Scale it later when you actually know where the pain is. That's the lesson I'd pass on.