After years of “microservices all things,” the tide has turned, and now the standard take is to build a (modular) monolith first. As an industry, we’re enamored with “best practices” that we arbitrarily set according to the seasons of the year—or whatever consultants are pushing on LinkedIn this month. But we shouldn’t follow anything blindly. Remember, it’s always a tradeoff. With monoliths, everything’s easy to access, and it’s definitely simpler to deploy—one big artifact, one push, done. But it’s also too easy to abuse that closeness, lose modularity, and end up with a tangled mess. And when teams grow larger, it’s just as easy for them to trip over each other—shared code, shared deadlines, shared chaos.
I think it’s perfectly okay to start with services instead of a monolith if the system is big enough to justify it. When you work with isolated, autonomous services, you get team autonomy, increased release velocity, and a ton of flexibility. Of course, that comes with the cost of more complexity—distributed systems are never free
Furthermore, you’ll probably get at least a few of them wrong—too big, too small, or just plain misguided. Expect to split or merge them as you learn. When your services are in this emergent, unstable stage, avoid building too many layers into them. Doubly so if they’re “micro” sized—cross that threshold into nano-services, and you’re just creating overhead for no good reason.
Complexity creeps in fast with services, so let’s talk boundaries. You do need them—these are your actual services. Within those boundaries, you might still have multiple “executables” or components—what I’d call aspects. Aspects can share a database (though you’ll want to minimize that sharing to keep things sane). They’re like internal helpers, not full-blown services. Think of it this way: a service is a sovereign entity with its own data, its own rules, its own lifecycle. Aspects are just parts of its machinery.
Not everything deserves to be a “Service” with a capital S. The folks who coined “microservices” still built them on SOA principles—autonomy, clean interfaces, and independent databases. That’s a lot of overhead for something trivial. If it’s small and doesn’t need to stand alone, maybe it’s just an aspect or a library, not a service. Don’t overcomplicate it.
And guess what? You probably won’t get your service boundaries right on the first try. Merging and splitting services is normal—it’s how you refine them. That’s why I’d say forget about piling on layers (at least for starters). Layers—like fancy abstractions or deep call stacks—lock you into decisions you’re not ready to commit to. Just try to keep it simple until the dust settles.
Enter AI coding
At this point, you might say, OK, boomer – but isn’t it all moot now that we can just vibe code? Fair question. If your project is small enough that one person can bang it out solo, then yeah, this post might not apply. Pre-AI, “small enough” was a tighter box, but tools like Cursor or WarpStream have stretched that limit, letting one dev iterate faster and ship more. Still, there’s a tipping point where a project grows big enough for a team or multiple teams, and that’s where these tradeoffs kick in.
These tools let you iterate quickly on the problem space and gain a better understanding of the solution domain without having to commit too deep to a design. , That understanding can greatly reduce the guesswork in carving out services, helping you nail boundaries with fewer stumbles – or even opt for a monolith after all. In the end, though, handling the tradeoffs and choosing right is (for now at least :) ) your responsibility
Another aspect, even more important if you want/need to design a large(er) solution – AI code will struggle with understanding it, and mastering it. You’d want to cut your problem into digestible (for AI) pieces; that’s breaking the system into services right there ( rather than keeping a monolith)
Using AI Coding tools can also greatly accelerate the ability to unite and split services and reshape boundaries.
Really -AI makes choosing services first more viable than ever before
