Hacker News Reader

Unique storage for multiple services sounds like a recipe for disaster. The purpose of splitting services, at least one of, is to decouple parts of the code at a fundamental level, including storage and overall ownership thereof. You're probably better served with a modular monolith if you really can't break storage up.

View on HN

No, only one service is reading/writing, everything else just call that. Still, things get quite lost when it involves talking to multiple other teams and needing to keep everything in sync.

Ok, but then what's the point of splitting it in the first place? The way I see it is to split your domain so that a team owns not only the code, but also the model, the data, the interface and the future vision of a small enough area. If a service owns all the data, then someone who needs to make any change is bottlenecked by it and they would need knowledge beyond their domain. So the key is defining the right domains (or domain boundaries). Unfortunately most people just split before thinking about the details of this process, so the split will sooner or later hit a wall of dependencies.

We need synchronous work flow and then asynchronous workflows. That was the primary reason. Now that doesn't mean it must split, but since we're running on multiple hosts anyway it wasn't hard to split off the asynchrounous functions to another batch.

Reply on news.ycombinator.com