Stop Building For Scale You Don’t Have

So, your system has 500 users, and it also has 20 microservices, including the gauntlet of Kubernetes, a message broker, distributed tracing, multiple different databases, and a pretty dashboard that probably nobody looks at. Someone asks the question, "Why is this so complicated for 500 users? " And usually the answer is, "Well, we're building for scale. " No, you're not. You're building for scale you don't have yet. That's a lot of extra complexity. I'm Derek from codeopinion. com, and while scale is important to think about, there's a difference between actually implementing it and just giving yourself the options. So, let's do that. Let's talk about how you can build for scale when you need it without paying all the upfront costs and complexity. Now, the word scale has a lot of different meanings and causes a lot of confusion. Before we clear that up, I'd like to thank Current for sponsoring this video. Current's an event-native data platform that feeds real-time, business-critical data with historical context and fine-grained streams from origination to destination, enhancing data analytics and AI outcomes. For more on Current, check out the link in the description. So, if you hear, "Well, we

need to split into microservices so we can scale independently," or that we need to add a message broker so we can scale more background work concurrently, or maybe something along the lines of we need to add a read model or separate database because our we had a read-heavy system, different shape of data, so we need to add a different database for read purposes. We're all talking about scaling. They all have different utility, but they're not all the same thing. That's why the word scale alone is just so vague. Are we talking about user scale in terms of number of requests, and you want to horizontally scale instances? Are we talking about splitting up into microservices because of for team reasons, organizational reasons, different teams have different ownership over different boundaries? We talk about database and read-write scale. Maybe you have a read-heavy system or write-heavy system, different shapes of data. Is it deployment scale, just how you're deploying different parts of your system, how each needs to scale differently. Scale is just so vague. Every pattern has trade-offs. If

you watch videos on my channel, you'll know that I'm really about trying to explain what the problems are, solutions to them, and what the trade-offs are. Because sometimes it's just not worth the cost of complexity. Now, all these patterns are great if you actually have these problems. Microservices for independent scale of code and teams and how you're deploying. A message broker doing background work, async scale, async processing. If you have multiple DBs for read-write scale if from a performance standpoint or just the shape of the data that you want to mutate. And things like Kubernetes for infrastructure scale. But, it all has costs, it all has trade-offs. If we're talking about microservices, most of everybody knows this here, you added a network boundary. You have contracts depending on how those microservices are communicating with other boundaries, deployment, versioning, observability, failures, retries, timeouts. The list goes on. Messaging, it experiences a lot of the same thing with retries, timeouts, uh ordering if you need it, duplicates, poison messages. If you have workflows, there's a lot of complexity in messaging. I have a lot of videos about it. Same thing if you have different databases. What kind of replicate is it using replication? Is there some type of eventual consistency or lag there? Are you creating some type of different shape of data where you have eventual consistency? Your application routing between Am I hitting the read database or the write database? Uh do I have some drift because of application code? Same thing with Kubernetes. Everybody knows the complexity of that. There are complexities, there are trade-offs. Don't add them if you don't need them yet. So, how do you build for scale so you can scale when you actually need to without having to pay all the upfront costs? Well, let's get into it. Now

let's start with microservices. And I'm going to say this phrase a few times so hopefully it sticks and you have an aha moment, is that a lot of people confuse logical boundaries with physical boundaries. So, my example here, let's say we have a monolith. We have all these different modules. A is coupled to B, B is coupled to C, C is coupled to D. We kind of have a rats nest of coupling, but this is all within a monolith. If we remove it from being a monolith and each one of these is now, let's call them microservices or services, we are still as coupled, even worse now that we've introduced network boundaries. We're not less coupled, we're not magically decoupled because maybe these things are using HTTP to communicate with each other or happen be that they're using a message broker, you're not any less coupled. All we've really done is taken that highly coupled monolith and turn it into a highly coupled distributed monolith. That's it.

If you take that source code, spread it apart in different repositories, that doesn't change anything. What we're really after is defining logical boundaries. How you deploy those physically, whether it be a monolith or different microservices, that's a different concern. What we're really after is logical boundaries and not creating a big ball of mud. So, people are thinking about microservices or services, they think generally, okay, we have a service that does something, it has its own source repository, and then that gets built into some deployable unit. Each one, service A, B, C, follows the same pattern. But that's really not the case and it doesn't need to be that way. If you're thinking about a monolith, you can still have these different logical boundaries, three of them, that are in the same repository that turn into one deployable unit. All I'm really referring to you here is the 4 + 1 architectural view model. It's stating that you have logical views, development views, physical views, and process views. Not everything needs to be a one-to-one-to-one. So, to illustrate this, this is what I

collect to call my loosely coupled monolith, and I'll start kind of in sections. So, we could have three different logical boundaries, and then they define things like contracts. Then, if this is in your monolith, these could just be like DTOs or interfaces or delegates, function definitions, etc. But, you'll notice each one of these, I have one single database instance, but within that, I may have particular schemas or tables that are owned by a particular boundary. So, we're already having segregation between where our code actually does, what feature sets it owns within our system, and the specific data that it references for read write purposes. There's not a tangled web of anything can reach the database and talk to anything else. No, they're talking to each other through APIs if they need to call other things related to data, actions that they need to invoke. If you're doing this, there's nothing stopping you at any point from changing what the physical boundaries are. That maybe I'll send you to deploy one particular logical boundary separately, because maybe it needs to scale separately in terms of requests, users. Maybe there the other two can still be bundled together. And you still have that single database. Nothing has to change but the deployment aspect of it. Again, logical isn't physical. We can take this a step

further. Maybe we need to introduce asynchronous processing because we need to do more work in the background, and you can introduce a broker for that. Maybe that's primary way that you actually want to communicate between your different boundaries. So, if we have some interaction that we need to occur, there could be some event that's occurring, for example, or some command that needs to be processed, we could send that to the broker, and we can have, even within our same monolith, another part of our boundary reaching to itself. Essentially, there were the producer and the consumer, just within different boundaries. Same [snorts] thing can happen here. If we split this apart, we're still using our broker to message between, okay, this instance, physical aspect of it from a logical boundary, could be referenced somewhere else. This could still all be within the same or a repo. They could be getting deployed differently. separately into, um, different services or together within a monolith. Logical is not physical. A monolith doesn't have to be a rat's nest of coupling. You can have defined logical boundaries, how you want to couple between them. It's the same thing with microservices. Yes, you can have a distributed monolith because you have a rat's nest of coupling, but it also doesn't have to be. If you're well defining what these boundaries are and how you're communicating between them. So, how this relates to scale is you're not ignoring it. You're actually building a path forward depending how you need to scale. If you have these boundaries and you need to separate something for independent deployability, you can do it. It's for team purposes, organizational purposes, you can do it. Now, another one comes up is async processing, async messaging with a

message broker or something like a distributed log. Yes, it has a ton of value and it sell solves actual problems like temporal decoupling where you can have two different systems or even different boundaries within the same monolith not online or available at the exact same time. It allows you to have buffering where you can have a little bit of back pressure so you have messages going into another system that are processed kind of as your abs and flows. You have reliability. There's so many different ways that you can deal with failures if you have a message that's durable sitting in a queue or a topic depending how you're processing it. One of the things I love about it is integration, especially when you need to deal with external systems. Something's happened a part of your system. You need to react to it through integrations and do talk to another system. And async workflows. Most systems that's really what's happening is there's a ton of workflows. Something happens, something else happens, there's some handoff. There's a ton of workflows in any types of business systems. But, there's a ton of complexity that comes with this. Like dealing with item potency because of duplicate messages, which is going to happen. And things like timeouts, back offs, retries, poison messages. There's a lot of complexity to deal with. So, you need to have the value there. If you're thinking about having to distribute monolith and we just maybe we're making HTTP calls from service service. That wasn't too great because we didn't have enough reliability and you're like, "Oh, well, we're going to move to something asynchronous. " Sure, but you still have all that coupling still. Another way of putting it is adding messaging, a message broker, an event log, an event-driven architecture. It doesn't solve having bad boundaries. So

ultimately it doesn't really matter if you have a monolith where it's in-process communication or using HTTP between services or a message broker or events. Ultimately, if you're temporarily coupled, you have to coordinate everything between them. If you're coupled by data, whether it be events or by a database, you still have to coordinate everything cuz if you have make changes, how does everybody know about these changes? And the same thing, if you're behaviorally coupled couple between services of knowing what to invoke on what service cuz it have performs what actions, you still need to coordinate everything. Ultimately, for

scale, it's about building a path. This does not mean building out a full-scale load architecture before you actually need the scale. But, you do need to find good boundaries and understand the distinction between a logical boundary and what something actually does and the capabilities it provides versus the physical boundary of how you're actually deploying it. That distinction is critical. It's about defining those so that you can build a path for scale. Now, get in the comments and let me know the most over-architected system you've ever worked on and what was in it that was trying to solve problems that you did not have. Get in the comments. And if you want to get access to a private Discord server, if you have questions you want to ask other developers about software architecture and design and topics like this, you can join my channel and get access post those questions there. As well as thank you to everybody that signed up, everybody that's a part of my community, I really do appreciate it. If you enjoyed this video, please give it a thumbs up. If you have any other thoughts or questions or different suggestions for other videos, let me know in the comments and please subscribe for more videos on software architecture and design. Thanks. — Mhm.