The Distributed Monolith Trap (And How to Escape It)

Quick takeaways

• Start with a monolith - don’t create microservices from day one; the overhead isn’t worth it until you have real pain points
• Microservices solve human problems, not just technical ones - they help teams work independently, not just scale systems
• Tight coupling over HTTP is still tight coupling - separating services doesn’t automatically give you isolation
• Watch for signals - lots of calls between services or frequent changes across multiple services suggest wrong boundaries
• Sometimes joining services is the answer - merging tightly coupled microservices back together can be the right move

Introduction

We talk about splitting software: when to do it, how to avoid common pitfalls, and why microservices aren’t always the answer. We share stories from past projects where we jumped on the microservices hype train without thinking through the real problems we were trying to solve. The key insight is that splitting software is more about organizing teams and maintaining good boundaries than about technology.

Notes

• The Domain Engineer training - includes a complex modular monolith example
• Modular monolith approach - starting with a well-structured monolith that can be split later if needed
• Event Storming - a technique for discovering system boundaries by mapping domain events
• Conway’s Law - the idea that systems mirror organizational structure
• Team Topologies book by Matthew Skelton and Manuel Pais - recommended for understanding how team structure affects software design
• Reverse Conway Maneuver - designing organizational structure first, then letting software follow
• Service mesh tooling (like Istio) - for observability between microservices

Quotes

This aspect of microservices I think can be also misleading. Because it seems like you have these separate things. You see the deployments, you see the different repositories. For an outsider, you can think they are separate beings that can be changed independently of each other. It can be a trap.

You can say that microservices are maybe solving a bit of technical problems, but it’s mostly solving the human problem.

So if you consider splitting your project, I would start with this question: if you even need to do it. Because you often see people struggling or hear them asking, I’m starting a new project, kicking off some application, and what services do I need to create? So probably at this stage, you don’t need to consider this at all.

I think it’s also nicely visible if you take your service mesh tooling, and probably will see that between some microservices will have a lot of calls going back and forth. And it’s usually the sign that maybe those two services shouldn’t be separate.

The more developers you add to the project, the more complicated it gets. Because this is also important factor. If you are a single person working on software like this, it will be fine probably because you can keep the context in your head. You will refactor to whatever you want. But if you have like 20 people working on it, it starts getting more complicated.

But there’s one good thing about microservices is that it’s forcing the boundaries really hard. So it’s hard to go over network if it’s not possible.

Timestamps

• 00:00:00 - Introduction
• 00:01:37 - AI and splitting software
• 00:02:42 - When splitting matters
• 00:04:39 - Monolith first approach
• 00:06:08 - Microservices hype era
• 00:09:34 - Microservices force boundaries
• 00:13:16 - The isolation illusion
• 00:18:31 - Merging services back
• 00:23:09 - Event storming for boundaries
• 00:27:41 - Core vs generic domains
• 00:32:05 - Bounded contexts and shared kernel
• 00:35:30 - Conway's Law and Team Topologies

Transcript

Miłosz [00:00:00]: So, if you consider splitting your project, I would start with this question: if you even need to do it, because you often see people struggling or hear them say, ‘How do I start?’ I’m starting a new project, kicking off some application. What services do I need to create? This aspect of microservices I think can be also misleading. Because it seems like you have these separate things. You see the deployments, you see the different repositories. For an outsider, you can think they are separate. Entities separate beings that can be changed independently of each other. It can be a trap. You have to think: what problem do you want to solve? This way, rather than just ‘Oh yeah industrial best practice.

Robert [00:00:41]: Probably, can say that microservices are maybe solving a bit of technical problems, but it’s mostly solving the human problem. Probably, you’re mentioning the monolith first approach that we are big advocates. We’ve tried it multiple times for products that become bigger later. If done properly, it’s working. It’s accelerating you a lot at the beginning and allows you to change it later.

Miłosz [00:01:05]: And what’s surprising to me, it’s not as popular.

Miłosz [00:01:11]: So, welcome after break. Let’s talk about splitting software, different ways of splitting software, and why it’s important in the first place.

Robert [00:01:20]: Yeah, I think it’s a good topic because, probably, it’s the topic that everybody writing software in this or another way needs to know how to do that. And if it’s not done properly, it may create a lot of issues.

Miłosz [00:01:37]: Probably even if we end up doing coding with AI in the next couple of years, it will be an important topic because it’s like one of the key architectural decisions you can make in your project.

Robert [00:01:50]: Especially, from our experience, even if people were doing that, usually they were missing that. And I would not expect that some cloud code or something like that.

Miłosz [00:02:00]: Handle it better than probably the opposite, actually, because there are so many anti-patterns on the internet. You know, like people tend to make mistakes when splitting software or do it in a very naive way. So yeah, I would expect coding agents to probably make similar mistakes.

Robert [00:02:20]: I think it’s you know not only about some inexperienced people—I think also sometimes very experienced people, without experience, may miss some signals from the systems. So when you’re building some system, it’s sometimes hard to miss some signal when something is going in the wrong direction. And it happens even for those experienced people.

Miłosz [00:02:42]: So it’s often the issue with big codebases, right? When we work with a big project, over time tends to be more difficult to work with, especially with bigger teams or multiple teams. And then the topic of splitting comes up. And I was thinking about, you know, our past projects on different companies, how important the problem is. And one thing I realized is that when we were working on our own projects before our full-time jobs, the stopping wasn’t really that important. Important so it tells me something right, that’s even if those applications were sometimes fairly complex, wasn’t. If it’s just you and maybe another person working on some project, it might still be fine sticking to one repository or codebase.

Robert [00:03:45]: Yeah, so probably can explain why, for example, people like Peter levels can have one PHP file that has 10,000 lines of code and he can work.

Robert [00:03:55]: But if you are two, also probably. But if you have people of five, ten, twenty, fifty people, it no longer works.

Robert [00:04:05]: When some application is done as proof of concept, later it evolves to some product that is making money. Sometimes it’s missing this. Transition phase from the application that was built as proof of concept by a team of five— even if okay, if you have team of five, it’s still not a big issue to handle, even very bad code, and be able to extend that. But when the team is growing, the product is growing, the number of features is growing, well, we start to have a problem. And the question is, what you do about that.

Miłosz [00:04:39]: Yeah, so if you consider splitting your project, I would start with this question: if you even need to do it. Because you often see people struggling or hear them asking, ‘How do I start I’m starting a new project, kicking off some application, and what services do I need to create? So we are probably at this stage, you don’t need to consider this at all. Right, because it’s not not the pain point, and the overhead may be big enough that it will not pay you back.

Robert [00:05:14]: So you probably are mentioning the monolith first approach that we are big advocates of. We tried it multiple times for products that become bigger later, and if done properly, it’s accelerating you a lot at the beginning and allows you to change it later.

Miłosz [00:05:32]: And what’s surprising to me it’s not that popular, or maybe now it’s probably a bit more popular than it was. I i see it mentioned here and there, but back back when we first tried it, I think no one talked about it that much.

Robert [00:05:45]: Yeah, but I think it’s probably still some small percent. And it’s maybe also a bit because of our bubbles. Yeah, maybe. But it’s still not.

Miłosz [00:05:55]: It’s not like a crazy different idea from creating microservices.

Robert [00:06:00]: But if you ask a random developer, what do you hear about? Kubernetes or modular monolith? I’m pretty sure I know the statistics.

Miłosz [00:06:08]: Yeah, the hype is a funny factor here. So I remember in one project—when I joined— we had one huge codebase.

Miłosz [00:06:20]: Typically, that’s the software no one wants to work with, and everyone would like to see refactored. And it was also around the time of the microservices hype era. So somehow we made a decision together as a team that we will split the monolith, as probably everyone back then did.

Robert [00:06:40]: Yeah, I remember how everybody was optimistic because it was like, ‘whoa,’ microservices. Finally, a solution for all of our problems.

Miłosz [00:06:49]: And when I think about it now, it’s funny how we had all these issues with this project and we assumed, ‘Okay, microservices will solve this for us I mean, the project was better in the end for sure, and I was responsible for the design of the framework and all the networking and stuff. So, as a programmer, it was very fun. It was great. Probably we followed the

Robert [00:07:16]: ‘fun’ principle too often.

Miłosz [00:07:18]: Yeah. But looking back at it, did it need all this complexity and distributed systems stuff? Probably not. Probably some parts could be simplified.

Miłosz [00:07:31]: But I think we just jumped on the hype train back then.

Robert [00:07:37]: But I think a good lesson from that was that you, as a team, saw some signal that ‘okay, there is something wrong with this project,’ probably it was like, ‘okay, we cannot maintain it, we cannot add new features easily.’

Robert [00:07:51]: So the problem was visible there.

Miłosz [00:07:54]: Right. So the question is whether splitting software is a good approach to fix these kind of issues.

Robert [00:08:02]: But do you think that maybe what would work better there was maybe a bit more balanced approach— so maybe a bit less microservices or staying as a monolith— was better.

Miłosz [00:08:16]: Maybe less microservices or modular monoliths for the start. Because the issue for sure was that the boundaries were wrong in the initial software, so there was, you know, some function calls all over the place from one place to another with no control. The more developers you add to the project, the more complicated it gets. Because this is also important factor. If you are a single person working on software like this, it will be fine probably because you can keep the context in your head. You will refactor to whatever you want. But if you have like 20 people working on it, it starts getting more complicated.

Robert [00:08:57]: But still, I think it’s still manageable with modular monoliths.

Miłosz [00:09:01]: Yeah, for sure. Yeah, but the issue is if you don’t have these good boundaries, you don’t know how to progress. Everyone tries to do something and it ends up as this big ball of mud.

Robert [00:09:14]: So in other words, you are modifying something in one place and everything around it goes up and you have no idea why. It should have zero dependency, but it seems that it does.

Miłosz [00:09:27]: Yeah, it’s risky and you don’t like making changes there.

Robert [00:09:30]: So the big bow of math or spaghetti code by the right, right.

Miłosz [00:09:34]: So if you have these good boundaries, as microservices, promised everything will be fine because you make these changes in one small Please.

Miłosz [00:09:45]: There’s low impact, you can deploy it independently from the other services, everyone’s happy, which makes sense, but you can’t do the same thing without microservices.

Robert [00:09:56]: But there’s one good thing about microservices is that it’s forcing the boundaries really hard. So it’s hard to go over network if it’s not possible. I mean, when you have a big ball of mud, you can call everything if you don’t have proper encapsulation. Okay, you can do proper encapsulation, but it requires some kind of regime of hardware. Or tooling, at least. Yes, yes. And with microservices, as long as you will not get exposed public endpoint, it’s not. So it’s probably showing why sometimes microservices may help. And have the same outcome with more cost, obviously. But again, if you go too far, it’s much harder to undo that because, for example, if you were wrong with modules in modular monolith, you can copy from one catalog to another, join everything. We have one module with microservices. You need to change your Kubernetes configs. You need to change all dependencies in other team services.

Robert [00:11:02]: It’s a mess, right?

Miłosz [00:11:03]: So maybe it’s easier to see the microservices as well because you can show someone, ‘Yeah, this is our Kubernetes deployments. They can see, okay, yeah.’ So this is your, those are your modules or microservices. The monolith is more complex because you need some kind of structure. It’s still possible, and we did that, but maybe not as easy to see.

Robert [00:11:28]: And I think there is also one thing that microservices may make easier out of the box. So this is all sort of observability, because you can put some Istio or whatever between those services and you have it kind of out of the box again, not for free. Yeah, with much less flexibility, because Again, it’s just put in the place by some cloud ops, DevOps team, whatever. But probably the flexibility is a lot limited. Right. From other side. You can achieve the same thing with your module monolith, but it requires some effort because you need to write it in code and you need to maintain that. other side, for example, I like this approach because it’s giving you a lot of flexibility. And it’s also removing some external dependency on the team that, in my opinion, should be more about running some transparent infrastructure rather than adding something like that. But from other side, it also depends because, for example, for some big enterprises, super big products, it kind of makes sense because you can have it out of the box and have it unified everywhere.

Robert [00:12:36]: So again, it depends on what kind of company we’re talking about.

Miłosz [00:12:40]: Right. So microservices are kind of more tangible. You have better observability. You can see them. And modules are more abstract. You have to more understand the project to see them. Yeah.

Robert [00:12:54]: But yeah, trade-offs. We are mentioning that to show that there is not only one way, because I think now the way with doing it with Kubernetes, with some service mesh, it can be a way. Definitely for some bigger companies. But again, if you’re working on a startup, maybe not— maybe you can do it by hand and it will be much more flexible, much more expensive.

Miłosz [00:13:16]: But this aspect of microservices, I think, can be also misleading because it seems like you have these separate things, right? You see the deployments, you see the— you know.

Miłosz [00:13:30]: different repositories. From an outsider, you can think they are separate entities, separate beings that can be changed independently of each other, but it can be a trap. I remember one project where, when we joined, they were described as independent and isolated from each other. So you can change one thing, it doesn’t impact the others. But it turned out the kind of isolation layer was HTTP API between them. So, on the outside, it looks like nice, clean separation. But in reality, they are still very tightly coupled. They just communicate over the network instead of function calls. I remember this confusion we had and trying to explain it to the management as well. Why this nicely separated system is suddenly a problem?

Miłosz [00:14:34]: Because from the outside, it looks like you have those tangible, separate microservices. The reality is much different.

Miłosz [00:14:43]: That’s also one of the hard parts: how to know. If the isolation is good enough.

Robert [00:14:51]: Yeah, and I think it’s often outcome of, let’s say, simplistic approach to splitting those services. So I would probably see two cases. One. We’re getting database tables and we have separate service for each database table. Hooray, microservices.

Miłosz [00:15:07]: I often see this when someone asks us, on Discord or whatever, for some feedback on a system they did. And very often it’s something like, ‘So I have this application. And I have users microservice and orders microservice. And at this point, I know this won’t be easy.’

Miłosz [00:15:31]: For most e-commerce systems, you can just separate users out of the orders, or it will be, you know, there will be some tight coupling probably between them anyway, as long as you’re not building some extremely big yeah, exactly. So it depends, but you know, if you take a fairly simple system, and you have those three main entities, and you think each entity should have their own microservice. Then you will probably end up with many problems because just separating those services won’t give you isolation. It will just give you this illusion of isolation.

Robert [00:16:13]: Yeah, and I think it’s also nicely visible if you take your service mesh tooling, and probably will see that between some microservices will have a lot of calls going back and forth.

Robert [00:16:26]: And it’s usually the sign that maybe those two services shouldn’t be separate. For example, those users and orders, those orders. So you can see that.

Robert [00:16:40]: To do an update to order or to do some shipment stuff or whatever, you need to call users many, many, many times.

Robert [00:16:50]: Can see that if, for example, you would need to add some field to, probably it can be customers, maybe not users in this case. So let’s say orders and customers. Commerce. And let’s imagine that orders is handing the shipment or something like that. And you can see the Skype link nicely when you have some new. For example, you need to add to user something that needs to be added to shipment. And in worst case, if it’s handled by two teams, a project that could be done in one day with modular monolith is starting to take one month because you need to go back and forth with two teams and agree on contracts and on everything.

Miłosz [00:17:30]: You have to wait for the other team to pick it up for the sprint or whatever they work with. So it takes twice as long at least.

Robert [00:17:38]: Yeah, yeah. And, you know, It’s often killing these small features that could be developed within one day or even if I code it now. Sometimes those features are that simple that it can be easily vibecoded. But with microservices, you no longer can because it needs to be orchestrated on a higher level. Maybe, you know, era of vibecoding will be era of modular monoliths. Hopefully modular. For sure, easier to deploy. But. And I think it’s also one important technique to mention when we are talking about these patterns, when we see that. So I would say that dark two signals when you should consider if something is wrong with us. One signal is when there’s a lot of calls between those two services to do some scenario. And the second thing is when you are modifying some functionality.

Robert [00:18:31]: It requires changes in two or many services multiple times. So you see this pattern over and over. And it may be a sign that it may be wrong separation of services.

Robert [00:18:41]: To solve that, there’s one technique that I think it’s very rarely mentioned because maybe it’s, I don’t know, some heresy for many people, but it’s the microservice station. So basically you’re getting those two services and joining them.

Robert [00:18:56]: And I know that for many people it sounds like a heresy. I hope it will change over the time.

Miłosz [00:19:02]: And yeah, it’s not never not easy, depending on how they are built.

Robert [00:19:06]: But Yes, but if you are getting into problem of changing those two services over and over and two teams that needs to do that, or even within one team, you need to always change two services and kind of synchronize how you’re deploying them. It may be worth considering if it’s worth investing in joining them. Because yeah, probably to introduce some costs, they need to do some kind of cost and income.

Miłosz [00:19:32]: Yeah, it’s a good thing you mentioned Teams because it’s also something I think you can’t skip when designing.

Miłosz [00:19:40]: Creating software, especially if you have teams working on the same project, maybe not the same code base, but microservices that work with each other.

Miłosz [00:19:53]: And if you have many of the services. I think once we worked for a company that had probably more services than developers or it was something like that, which sounds funny now, but I think it’s the reality for many companies actually. Because when it’s easy to spin up a new service, maybe you have great tooling and some platform team that handles it for you.

Robert [00:20:16]: It’s interesting risk, actually, of having great tooling for easily creating microservices. I mean, if it wasn’t easy, you would think twice before creating a new microservice.

Miłosz [00:20:28]: If creating that takes one minute, you end up with teams who own 10 or more. Microservices for very simple tasks sometimes I don’t know— maybe it’s fine. Sometimes, for things like keeping avatars, for example, so it’s like—overhead— but I think the most problematic story I remember from from this was where there were some services that had no clear owner, and we both our teams and other teams’ responsibilities kind of crossed in one area. That’s not really a technical issue—it’s funny, that’s like a team organizational issue. Mm-hmm.

Miłosz [00:21:19]: And it’s very difficult to figure out if you didn’t start with a good design of the system first, but you just, you know, added the microservices for this entity here. This entity here— this entity here— maybe this database table sounds like a separate service, and then you have to kind of— you know— create some teams and you assign them the services. Artificially. Yeah. So that’s not a good idea.

Robert [00:21:47]: And two years later, if somebody asks why those services are like that, it’s: ‘It was always like that.’

Miłosz [00:21:54]: Why you ask? Yeah. So we finally figured it out somehow, but it was very painful.

Miłosz [00:22:02]: Not only because of the technical challenges, but also all the discussions between teams, company politics, stuff like that.

Robert [00:22:13]: What I remember was useful there. So in this scenario, we used event storming for that to discover that. But you don’t need to use event storming. You can use any technique to see how the flow of the system is going. And I remember that it was quite funny to see that entire critical flow of the application was. So, for example, the beginning of the flow was owned by one team, later it was some small element owned by another team, it was going over again to the previous team. And it was a lot of some small pieces. Crossing the boundary. Yes, yes. And those were usually the biggest problems because if something didn’t work, it was sometimes not clear who is responsible. And it was also harder to change this law because if team didn’t have entire ownership of this law, they were just not able to do it without some cross-team coordination.

Robert [00:23:09]: Well, what we did there, the solution was quite simple. So it was looking on high level on this and trying to understand how we can change ownership.

Robert [00:23:19]: Historical ownership, and it helped a lot. And we added also to that a bit of the microservice station, and it helped even more.

Miłosz [00:23:26]: I thought about even storming when you mentioned service mesh visualization.

Miłosz [00:23:31]: So maybe instead of using this visualization after the fact, after you have the microservices in place, you could just have this high-level plan with even storming or not.

Robert [00:23:45]: Seeing how system works before it works? How?

Robert [00:23:49]: How is it possible?

Miłosz [00:23:51]: What kind of magic is that?

Miłosz [00:23:54]: Try to design it first and then see. But you know, it’s also not that easy, right? Because it’s not just a UML. Diagram where you have users, orders, and you see—okay, this is separate, but more like ‘yeah,’ maybe that’s why I would still recommend event storming because it focuses on behavior, not on the entities. So, if you map the events that happen, then the behaviors you can see there are some— those clusters of things that happen together— and it probably means they are a good place for some kind of boundary. And if you have, for example, two clusters that are joined by two events or something like that, you can clearly see, ‘okay,’ those things can be mostly separate and they won’t interfere with each other. They won’t be tied up.

Robert [00:24:53]: And I think what’s also pretty good there, compared to some UML diagrams, is the context of time. And because, when you are looking at UML diagrams, you cannot see the order of flow. Even storming is more so for people that don’t know how to it looks like. So TLDR is that it’s basically some brainstorming session when you’re putting sticky notes for domain events or whatever events that are happening in the system. And you don’t need to do event-driven architecture for that later. So it’s more for the high-level modeling and how you implement that later, whatever. And what’s nice, it’s putting the in time order.

Robert [00:25:32]: So basically, when you have flow, you can see when the flow is starting, when it’s ending, and it’s kind of in a magical way helping you to see how to do the split there. Anyway, I think it’s a big advantage compared to those UML diagrams or in general some diagrams.

Robert [00:25:52]: Flow diagrams probably are a bit better because they also go from left to right, but I think they are not readable for very complex systems. You cannot make a flow diagram for entire system. Don’t try. But with event storming, basically you can do super big systems on higher level, but you can see the big picture of it.

Miłosz [00:26:16]: So it’s a great technique if you’re just looking for the boundaries, or even if you have an existing system and you want to see how it could be done in a different way.

Robert [00:26:25]: If you would like to hear a bit more about event storming, we’ve been discussing it one episode earlier, two episodes earlier, something like that. That so check it out but okay let’s come back to splitting.

Miłosz [00:26:38]: So the nice benefit is of having everything mapped out on some whiteboard or you know some software. Is that you can look at it from different perspectives. For example, one thing you can do is try to differentiate core domains from the generic domains. So for example, you can see some cluster where there is more of your domain language of what your software is very specific. About, different from other software. This is probably your core part and it might be one cluster. And maybe there are some parts that are more supporting, more generic and they don’t need to be involved as much. So they don’t need to know all the details of your domain. Very often this helps you to simplify this part. For example, it can be some e-commerce software or some account.

Miłosz [00:27:41]: Mounting software you can just buy, or you know, wipe code, or whatever— you don’t need to build it yourself from scratch if you don’t want to.

Robert [00:27:51]: So, in other words, not all software in your product is equal. So some parts of software probably require a bit more of love.

Miłosz [00:28:01]: And the less they know of each other, the cleaner your boundaries and the simpler the software as well.

Miłosz [00:28:08]: So even if you build yourself this generic part, I would do it in a way that it could be reused in a different company.

Miłosz [00:28:18]: It doesn’t mean you need to do it in the end, but it often helps to keep these boundaries clean and just keep some translation between them. Hmm-hmm. Of course, it can also be overdone if you try to make it super generic or use cases. So you have to be careful about that. But in general, I would try to not let the domain terms spill out of the core parts.

Robert [00:28:48]: Yeah, I think it’s also some other direction that sometimes you can also watch out for with buying things because, it sometimes works that there are some services that are generic enough that can buy it, like sending emails, sometimes accounting software, but it depends. So sometimes when you are handling very specific things like marketplaces, you might not find accounting software that can handle it for you. I mean, for example, you are building some food delivery application. I guess you won’t find accounting software that will handle it for you. So it’s kind of interesting, because if you’re building this kind of application, it’s not your core domain, probably, but for other sites, it’s a very important domain. Unit also yeah— probably building a house, but parts of it will be generic, right?

Miłosz [00:29:42]: Like printing invoices, that’s probably something someone solved some time ago and you don’t need to write it from scratch. Or if you do, we can keep it very generic.

Robert [00:29:52]: Or maybe, for example, trying to understand what’s art. tax rate for each country is a good type. I mean, you can probably hire an entire team that is spending their entire time researching what the rates for every type of food or whatever that you can have in any countries. But probably you can just buy it from external company. And other techniques for event storming. So maybe not forever event storming, but I have also in mind one thing that you mentioned: sometimes you have parts of the system, some maybe services, maybe some libraries that multiple teams are kind of owning. And sometimes it’s on the pattern, but I think sometimes it’s also not, because sometimes it can happen. For example, from domain-driven design, we have concept of shared kernel, and it’s there for some reason. So sometimes you have some parts of code that two teams need to share, need to own. M. You can use it, but I would say that it’s rather an exception than something that you need to use by default, because if you try to use it by default, probably you’ll overuse it.

Robert [00:31:02]: But I think it’s also important to keep it in mind that sometimes you have some things like that and it’s also fine.

Miłosz [00:31:09]: Yeah, it’s a very important decision when you have two teams working with some similar entity or the same entity in different contexts. So first, there’s also the bounded context concept from DDD. What I think about it the most is exactly this situation when, for example, you have this user entity which can be also a customer entity in another context and, in other contexts, be something else. And you have multiple teams working with it. One naive approach would be to deduplicate and create one main user that decides about everything and has all the fields and behaviors and so on. But it that means all teams share this part and you know they need to agree on how to develop it or, from other side, if you’re one team, don’t that because it will just create too much overhead.

Robert [00:32:05]: And this was something that we see often: there was one team and went too far with all those patterns.

SPEAKER_2 [00:32:12]: And later, it’s like, oh, no, Domain Driven Design is making our software so complicated.

Miłosz [00:32:19]: Yeah, but if you have multiple teams, you can use the bounded context concept. So you try to figure out how this user entity works. Different contexts may be separate; you know, maybe both teams can have their own user entity and they are completely separated and that’s fine. And sometimes you have this shared kernel, as you mentioned. So some parts that are so common and probably specialized.

Miłosz [00:32:49]: Like you mentioned, maybe the tax rate calculation, something like that. But it doesn’t really make sense to separate that. You just agree, okay, on this small common part. We will work together and you know both teams— for example— need to agree on reviews and stuff like that on the design of it instead of the entire big system. So when I think about what’s difficult about this problem of splitting software well, I think it’s a combination of organizational and technical complexity. It’s not just one thing.

Robert [00:33:23]: So sometimes I remember that there are some companies where the teams and services split and organization is somehow going from the top. Maybe it’s not from the top, but level or two levels higher than you are.

Miłosz [00:33:39]: Or another way is that it became kind of the default to create microservices, and very often in a naive way.

Miłosz [00:33:50]: So, for example, when I joined some project and there was some kind of migration happening from an old system to a new one.

Miłosz [00:33:59]: A few people in the team assumed, let’s use microservices from the start. It’s kind of like a default approach for some people, but it can be a trap. Because you have to think, what problem do you want to solve this way, rather than just, ‘Oh yeah, it’s the industry best practice.’

Robert [00:34:19]: Worse if you have problem that you’re trying to solve, because sometimes people may think, ‘Yeah, we have problem with I don’t know scalability or ‘We had overcomplicated POC earlier and microservices will solve our problem.’ Yes.

Miłosz [00:34:36]: So it’s helpful to think of microservices. Deployment patterns, something we discussed some time ago, I think.

Miłosz [00:34:45]: It helps when you want independent deployments, for example, for different teams. That’s a good excuse to split software.

Robert [00:34:56]: Or for example, you have that many deployments of your module or monolith that the queue is longer than you. I mean, queue is long enough that not every person is able to merge within one day. Probably it’s already designed that you can split it.

Miłosz [00:35:13]: So it’s connected to teams and how you organize developers.

Robert [00:35:20]: So in other words, probably we can say that microservices are maybe solving a bit of technical problems, but it’s mostly solving the human problem.

Miłosz [00:35:30]: Humans working together problem.

Miłosz [00:35:33]: There’s Tim Topology’s book. I’ve read some time ago. It’s great. I can recommend it. It’s specifically about this problem with the reverse Conway maneuver, I think it’s called. So basically, instead of creating a software first and then trying to assign people who work on what, you do it the opposite way. So you first design, as we mentioned, event storming, a bit similar idea. You first design the organizational structure you want to have in place, and then the software system follows that.

Robert [00:36:08]: I love when such old patterns, like always low, are still working those days.

Robert [00:36:14]: Even if people don’t realize, but, but I think. It’s good to know about some that something like that exists, because you can be a bit maybe more mindful when you’re doing such decisions. And it’s not like, oh, just everybody’s doing that or we’ve been doing it like that for ages, why we should change it. Yeah.

Miłosz [00:36:36]: It’s also great that we are past hype. Era now and many people talk mainly about how complex microservices can be. So now it’s probably we are more balanced.

Robert [00:36:47]: Probably won’t you won’t be put on the stake after saying that microservices is not the only way.

Robert [00:36:55]: Maybe in 10 ways we’ll be again in the place when everybody is using monoliths. Probably not modular, something tells me. Probably it will be still a problem.

Miłosz [00:37:06]: I think, as an ending note, we can recommend starting with monoliths if you are just getting started, especially if you are just a single developer or a small team. Yeah, I hope we should. And do it the modular monolith way.

Robert [00:37:20]: Yeah, I hope that we’ve shown that there are alternatives and it’s really not that hard to do things in those alternative ways.

Robert [00:37:30]: Definitely will not finish with this episode about modularization because it’s a topic that requires a lot of attention, in my opinion, and it can give a lot back— i mean, when you are doing it properly, it can really accelerate your work a lot, yeah, especially with modular monolith.

Miłosz [00:37:49]: Because I think what we’ve figured out works pretty well.

Robert [00:37:54]: And we’ve seen it work with teams. And we also see that it’s not that popular approach. So I think it may be also some unique skill to have.

Miłosz [00:38:04]: Yeah. And if you’d like to see a real example of this, we have a domain engineer training coming up and we will have an example of a pretty complex application with different modules built as a modular monolith. And we mentioned parts of it in this episode as well. Yeah, I think it will be cool. So we’ll leave a link in the description if you want to learn more. So we shared our stories with Spitting Software. Let us know about yours so we can also learn something and maybe help you figure out something.

Robert [00:38:40]: Yeah. So we’re here to help you. So this podcast is for you. And yeah, if you will be happy to answer in comments and maybe include something in the next episode as well.

Miłosz [00:38:53]: Yeah, if you have any topics you would like us to cover, let us know.

Miłosz [00:38:58]: See you in the next episode. See you next time. Bye. Bye-bye.