> I'm at this very moment gearing up to begin a new large project and am wondering what design makes the most sense IMO a monolith is always the starting poin

> I'm at this very moment gearing up to begin a new large project and am wondering what design makes the most sense IMO a monolith is always the starting point until your team gets big enough to justify breaking it up. > Seems like this could be dealt with by applying more discipline and just making sure to design things to be more modular and.. separate This really depends on the team size. As you get above, say, 30 engineers contributing to your codebase daily communicating those logical boundaries becomes nigh impossible without significant operational overhead. You either accept the chaos and let your codebase become a Big Ball Of Mud (most common) or you introduce so much process overhead that your team paradoxically gets slower the more people you add. I'm sure there are exceptions but it's rare. > Do we need an entirely different architecture, with all the pitfalls that microservices entail, because we can't seem to keep things clean and separate? Microservices are probably not the tool to reach for no. Several "fat" services separated along some kind of bounded context within your domain? I've seen that work great as a next step in a monolithic architecture evolution. Teams can have the autonomy they need to make decisions quickly, separation of concerns is enforced by the network. The extra overhead incurred isn't untenable since you only have a few services instead of a hundred.