Distributed vs. Universal Data Model: Essentials for Distributed Architectures - Venkat Subramaniam

This talk explores the differences between distributed and universal data models and their significance in distributed architecture. The speaker emphasizes the importance of understanding what type of architecture one is actually building, whether it be a monolith or microservices. They discuss the various factors that influence decision-making in software design, including encapsulation, cohesion, and coupling. The concepts of bounded context and data representation are examined, particularly in the context of domain-driven design. The speaker outlines the benefits and trade-offs of using a universal model, which centralizes data but may lead to low agility, versus a distributed model that offers higher business agility and encapsulation but may struggle with consistency and reusability. Ultimately, the speaker asserts that the choice between models should be guided by specific application needs and business requirements.

[music] >> We're going to talk about uh distributed versus universal data model. And we talk about why this is really essential for uh distributed architecture. But before we dive into the ideas of distributed architecture, let's step back a little bit and talk about uh things that we should probably consider before discussing a distributed architecture. Uh we've been in this wave of different architectural styles or architectural patterns

over the past few years. Well, it turns out for for a long time, we've been building uh monoliths. And then off late, people got excited about building things like microservices. So, one of the first things to really think about is is it is it important to build microservices? Is it important to build monoliths? And and we have come to the point where uh quite a bit, we

get really excited about building microservices, and everyone wants to go build microservices. The the problem really is that it's not about what you think you are building, but what really it comes down to is what are you actually building. And you can call it whatever you want to call it. But if it's not what it really is, you're not going to get the results out of it,

unfortunately. So, essentially, I can say that I'm building microservices, but am I really building microservices? Why am I building it? How am I building it? And what results am I expecting? Am I getting those results? We need to really rethink about it. So, when it comes to uh applications and architectures, there are a few things we often uh think about, and there are a few things we

often uh consider. So, let's step back for a minute and think about it. So, the first question is, you know, what is a monolith? So, and and and and again, whereas what is you know, microservice, right? So, essentially, when you ask this question, it in in in terms of this, you you may use the term, you know, what is a monolith, whereas you could say what is

architecture. Now, unfortunately, one of the problems we often face is we in general as as you know, software people have a really hard time naming things. This is very very difficult for us and and we really struggle to come up with good names. And then when we come up with bad names, it becomes really misleading and hard to understand. Think of the fact that a really a

bad name, NoSQL. What a terrible name, right? Why would you call it something as no of something? Or you talk about wireless. Why do you say less of something you're not using? And this is one of the struggles we have, right? In terms of what do we call things? And and so, if I tell you monolith versus distributed, it implies something, right? That monoliths are not distributed

because you're comparing and contrasting them. But, the question is, are monoliths really not distributed? I've been writing softwares for about 40 years and even the very first software that I was involved in writing, we had a desktop application back in time that spoke to several application services which were running on other machines and then we were also talking to a remote database which who hosting all the

data. so even that system 40 years ago had about four or five different systems it spoke to. is that a distributed system then? So, then the confusion arises. And so, the first thing to keep in mind is mono you could say is also distributed at runtime. So, this is really where the confusion starts because we have almost never built any serious system where it was one big

blob and it never spoke to anything else. That's never happened. So, then the question comes back to, you know, then what in the world, right, world you could say is monolith. So, that begs the question. So, monolith you could say is about having a single unit of deployment. So, this is basically the bottom line for a monolith. So, a monolith is about having a single unit of

deployment. So, what that means is I can say that my monolith contains maybe three parts. And and here is part one, here is part two, and here is part three. These three instances are running. But, all the three have to be running and if I want to upgrade, I upgrade them in one single unit. I don't have the luxury of upgrading one and not touching the other.

So, they are often very intertwined that when you upgrade one, you also combine the upgrade of other things. So, this is where the unit of deployment comes in. So, if you ask me, when you upgrade, what is it that you're going to upgrade, my circle will include all the three together. And you you have to upgrade them all. Let's think about this and see how that is.

So, imagine for a minute that I have one service running here, and I have another service running here, and both of those services are talking to this database. So, now I have the database sitting here, I have these two services, and those two services are pushing data and pulling data. Now, I decide this service needs a to to change the way the data is represented. So, I'm

going to change the data that's represented. In order to do that, I'm going to modify the schema in the database. Well, the minute I modify the schema in the database, this application is not going to work because that is not in alignment with the data. So, I have to upgrade this also. So, now in order for me to make this change, I've got to change all the

three together. Otherwise, I change one and the other one is broken. So, I don't have the ability to say, let me just change this, I can worry about changing that some other time because there's a dependency across those things. That matters a lot. In a in a distributed architecture, you have multiple units of deployment. That is the deployment that matters more than anything else. So, you can

say distributed, you can say you know, architecture, you could say you know, has in this case has multiple units of deployment. So, what that means is I can upgrade this part without having to upgrade this one. They can they can evolve independent of each other. Now, obviously, you may say, how can you upgrade one and not have to upgrade the other? Well, this really fundamentally comes back

to decoupling these parts for us to be able to do this. So, let's step back for a minute and think about some of the fundamentals we should be thinking about in general. So, we often think about a few very basic things, right? We think about encapsulation. So, what is encapsulation? Encapsulation is really separation of what something does from how it does that. So, this is a separation

of what's from how. What is the benefit of that separation? If I tell you what I do, but I don't show you how I do it, I can change the way I do it, but you're not going to be affected by it. So, I'm able to evolve the implementation without affecting the users of that service. Secondly, from your point of view, you are not going to be

affected by the changes I make. This is one of the things that encapsulation brings together. If you don't have encapsulation, the two sides cannot really be stable because if one changes, the other breaks. And and you are not going to change much because you're afraid if you change, they will be affected. This leads to what's called rigidity. So, rigidity comes from your fear of change because when

you change something, you're going to affect something else. So, the flexibility to evolve the software goes down when you are when you don't have much encapsulation. So, that is one of the fundamentals we often need to think about. The next thing to think about is cohesion. Cohesion is where like things together and unlike things apart. So, if you think about, you You how these things are related

to each other. The things that are used normally together will stay together. The things that are not normally used together will stay away from each other. For example, if you look at this table here, what you see is all these electronics and audio equipment. Well, that makes sense because these are being used with each other. On the other hand, if you look over here, there are these

bags all grouped together. Well, why are the bags not mixed up with that? Because you don't need the bags right now when you're working with the equipment. That's a separation and we have cohesion. Humans use cohesion to really deal with complexity. If you put things in the wrong place, it becomes really hard to get to things and that becomes expensive. Same thing applies in code. If you

keep things away from each other and the things that are together change together. That is one of the most important thing. This is really fundamentally that you are trying to do. There's a single, you know, a reason to change. So, you're really looking for a single reason to change. So, in other words, the things that are together change together. Things that are away from each other change

at a different frequency or at different intervals. That's basically what cohesion really gives us. The third thing we often talk about is really coupling. And coupling is dependency and and how things are dependent on one another. And and the problem with coupling is this. You cannot work without any coupling and you cannot work with a lot of coupling. And and coupling is something you need a little

bit of, but once you cross that, it becomes a problem. And and if you go to the left, you're going to be in trouble. You go to the right, you're going to be in trouble. You got to find that nice sweet spot where it's okay to have that much of coupling. We'll talk more about this in a few minutes. Then we talk about a few other things

we often care about. One of them is a dry. Dry stands for don't repeat yourself. So we want to avoid duplication. Now this is something we carry a lot forward. We work extra hard to remove duplication. We frown upon duplication often times. So as a result we try to reduce the duplication or where things are being repeated. We can also come up with really fancy names to

convince ourselves about things. For example, a term you would hear quite often is single source of truth. A single source of truth means where do you go to find something that one place. And and so often times we'll convince ourselves that a single source of truth is extremely important. So we often look at it also. And one of the holy grails in software development is reuse. We

work very hard in order to increase reuse often times. So that is something we strive towards. So what is that we really like in general? We really like high encapsulation often time. So if you ask people should I have more encapsulation or should I have less encapsulation? The answer is we need to have more encapsulation. Because if you have more encapsulation, then it becomes easier to make

changes without stepping on each other's toe. So we want to really have more encapsulation. Similarly, we want high cohesion. If the cohesion is high, things are really sticking together where they are needed. And that's a much better way than having low cohesion. Hey, what about coupling? When it comes to coupling, we often want to have low and loose coupling as well. So, we want low coupling, but

we also want loose coupling. Why? Low coupling leads to So, if we don't have low coupling, right? So, you know, helps to lower fragility. So, essentially if if if if a high coupling, the code becomes more fragile. So, it breaks too often if your code depends on too many things. So, if my code depends on seven things, if any of those seven things change, I'm going to

get affected. If my code depends on fewer things, that reduces the chance of me having to change. So, it reduces fragility. That's one of the benefits we get. What about loose coupling in general? Well, the beauty of this is loose coupling improves extensibility. So, in general, if your coupling is loose, it's easier to extend your code. If your coupling is not loose, it becomes harder to extend

your application. That's one of the reasons why we really try to really fulfill that. And And what about dry? We often want high dry. So, dry basically is you want this to be reducing duplication. So, if that dry is high, you have less duplication. If If dry is low, you have more duplication. So, that is basically how this works. And of course, you want high reuse as

well. So, when you ask people, "What would you like?" we would say, "I want this. I want this. I want this. I want this." And it's easy to say this. But here is the problem, right? So, uh those uh you know are what we desire, but uh sadly, we are in conflict uh you know in uh in that case. So, what is the conflict? The problem is

if you uh reuse, you also increase coupling. So, think about that for a minute, right? If you increase reuse, what happens? You are saying, "My gosh, this is here and this is here and this is here and this is here. We don't need this to be in so many places. Let's bring them together, and now we can reuse that from multiple parts." Well, if you reuse things

from multiple parts, what do these multiple multiple parts do? They have to depend on that. So, as a result, we increase the coupling. Now, look at the contradiction, right? If I ask you, "Do you want more reuse?" you say yes. If I say, "Do you want more coupling?" you say no. But if you increase this, this increases, too. And if you decrease this, this decreases, too. And

now you're like, "Gosh, how do I increase this without really increasing this?" And the uh problem is you cannot, right? This is like a seesaw. The on the seesaw, if you sit here, this goes up. And you say, "Wait, wait, I want to sit here, but I don't want this to go up. How do I do it?" Well, that's the nature of a seesaw, they're connected. So,

that's where it's a tug of war between the two, and and it it affects it. You cannot eliminate it. In a similar way, you can say uh if you increase DRY, you also decrease, unfortunately, encapsulation. how was that? So, if you think about it, if you increase dry, you also decrease Well, how could that be possible? Well, I want this part of the code to have the

same data as this part of the code. So, I'm going to put them into a database, and I'm going to let these two use the same database. Well, if the two things are using the same database, what happens? The this system now is aware of the implementation of the data that this system uses. So, that is what encapsulation is, right? Encapsulation is hiding the details. So, if

I ask you, "How is that implemented?" your answer is, "That's none of your business." Right? I don't need to tell you how I do it. I can tell you what I do, but the minute you put in the database and open up the schema, both the sides know of each other's implementation. We lost encapsulation. So, this is where if you modify that schema, both of these are

affected, and you got to change them together. That's how monoliths are born, right? All these three are now interconnected, and the big circle around them, you change one, you got to change the others as well because they are very interconnected with each other. So, so this is where the these things appear to be things that we want to go after independently, but as it turns out, they

are quite connected with each other and influence to you know one another. So, the question is, which one should we really be deciding towards is the question. So, so which which of those of these you know are important? And and there's no really good answer to this, right? So, what should really be the one we do? And the answer to that is uh it really depends on

the application application uh needs. So, you cannot universally say this. If you say, "Which of those is important?" I cannot tell you that. Well, I'm going to ask you, "What are you doing?" Your application needs make the decision where we need to be leading towards, which is more important. So, this is something for us to think about in terms of which one we should, you know, lean

towards, if you will. So, having said this, how do we go go ahead and quite manage these things? Let's park those ideas. We'll come back to those after visiting a few things. So, you're building an application, and what are the things you should represent in your application? Now, let's step back for a minute. The we are we are working in a field where things change very rapidly.

Well, at least that's what people will want you to believe, right? "Oh my gosh, things change very rapidly." But, it actually takes a long time for us to really embrace ideas and make really good use of it. You know, people talk so much about uh microservices, and we talk about how we should model data across microservices. As it turns out, one of the books that really talked

about this came a very long time ago. Uh more than 30 years ago, which is shocking. And that book talked about everything about without using the word microservices. Because that book was written at a time when the word microservices was not available or was not being used. So, this book entirely talks about how to design and model and architect microservices without ever saying the word microservice and

I'm talking about Eric Evans book the domain driven design book. So domain driven design, that book is one of the most difficult books to read but when you read it, you reread it and reread it and then you begin to realize how much valuable the information in that book is. But in domain driven design Eric Evans talks about how do we model things within an application? Well,

the very first thing is association. So what is association? Association really is a relationship between things. So association, you know, it is a way to represent relationships, right? So relationships between you know, things. So essentially we all represent association of the data. You know, database, you often talk about foreign key relationship. In object modeling you say this object refers to this other object. Association could be more

refined into aggregation or potentially to composition as well. So this is a very common thing we need to be thinking about. But on the other hand, you would also want to think about what are called entities. So what is an entity? So entities have identity. So an entity has an identity. In fact, it's you could say entities have unique identity. So what would be an identity an

entity and an identity in a system? I have credit cards as so as as almost everybody in this room is, right? But what's your credit cards ID? So if you call the credit card company and say, "Hey, I've got a charge on my credit card. I need to talk about it." What do they first ask you? Uh, "Excuse me, what's your credit card number?" Well, the credit

card number is unique. If I have a credit card number and you have the same, we're in trouble. Unless you we both are related, right? So, my wife has the same credit card numbers as I do, and that's perfectly fine. I charge, she pays, everything is in harmony, right? So, the point really is that we need can share, but it's only when it's the same credit card

that we are talking about. That's same account. But, two different accounts would have a two different identifier. So, essentially in this case, we have a a unique ID to represent entities. Similarly, you can uh call the insurance company, and they may say, "What's your you know, ID?" Uh, you know, in the US we talk about social security number. I'm assuming you have similar numbers, right? Uh, other

numbers I've heard. I don't know how far that's being enforced, but that could be a way to really use this information as a way to reference. You could do that. Or sometimes, you have other ways to identify. You may have a bank account, the or you may have a a driver's license number. So, all of these are ways to to specify, but they are all referring back

to entities. Entities have unique IDs that you represent. So, entities often represent these uh uh you know, instances or objects that carry around certain data under an abstraction in a system. And and so, when you have these entities, what do entities have? Entities have a a collection of value objects. So, what are value objects? Value objects uh you know, do not have uh uh identifiers, right? I

do not have identity. So, you cannot refer to a value object directly. That is often times not allowed. For example, I call my bank and say, "Hey bank, I see a transaction on my account on the 23rd of April, and I don't think that's a valid transaction. Can you please help me?" And and they say, "Well, sure. Let me let me take a look at it." And

you say, "Sure, let me give you my transaction detail. It is on April 23rd, and it's a third transaction on my account." And what does the person at the bank say? "Hang on, hang on. That's not going to help me. I want to know your account number, right?" So, you don't give them identities for value objects, you give them identities of the the entities. And once you

give an entity, they can then say, "Aha, there we go. We pulled your account. Let's go through and verify if you're authorized to talk about this account. Okay, now tell me what your problem is." Now they have the identity, which is the they have the entity, which is the account. And now you can say, "In this account, I have a problem with the transaction. Right now, let's

go find the date." And and under the date, let's look at the transaction, and now we can see what transaction it is, and we can talk about it as well. So, essentially, value objects are often members of these entities in general. But there's one thing we need to keep in mind, and that is value objects are are immutable. So, value objects are immutable. What does immutable mean?

Immutability means once you create something, you don't modify it. And it's it's frozen in time, and you're going to just keep it that way. Now, think about this for a minute. If you ask me what's my address, well, here's my address. Well, I decide to move to a different address. When I move to a different address, if you erase my address and change it to a new

address, that means you modified that particular object, in this case, the value object. Well, addresses are value objects for a person who could be an entity. So, what you typically say is, "No, no, no, we're not going to do that." Why? Because here's the matter of the fact, uh you there are times when I need to specify all the addresses I have lived in for the past

what, 7 or 10 years? So, I can say this is my current address, but these are my previous addresses. So, every address is immutable. So, once I create an address, that address is exactly what it says. I cannot erase it. I cannot say, "Change this door number. Change the street name." I cannot do that. That is frozen. I can point to it and say, "That's my current

address." And I can point to my previous address and another previous address, another previous address, but that's my current address. Hey, what if I move? This one becomes a previous address, but a new one appears and I reference to it. So, value objects are immutable. Now, you say, "What is the benefit of immutability?" Right? That is something we need to understand. So, immutable, so immutability, you can

say, right? So, uh makes it easier to reason about code. So, if something is immutable, it becomes very easy to reason about code. You have this value, it's not changing, and because it's not changing, you can talk about it and say, "Here is how the code works." And you're able to get a really good view of the data over time. That makes a huge difference. Not only

that, there is another big benefit of immutability. And And this is the fantastic benefit, right? So, immutability makes it easier easier uh and safer uh to share or to copy. This is the beauty of uh immutability. It gives you the power of both. Immutability makes it easier to share and easier to copy. So, let's say for a minute that this is uh immutable data. Well, because this

is immutable, I can put it here, and I can say, "I want to reference it." And you can say, "While you are referencing it, another system, another part of the system can also reference it." So, you can have two references or more referring to that because that is immutable. So, that is the power of immutability. But you say, "Well, that's great. Thank you. Because it's immutable, multiple

things can reference it." Well, what if it's mutable? One is Both are referencing it. One changes it, and the other is in trouble. It's like, "Wait, that's not the value I saw earlier, and I need to protect it." So, now what do we do? We apply locks on things. And I'm going to lock it, and then modify it, and you need to lock it, and then you

fetch it, and we lead to all that mess. But there is another benefit to this. And that is you say, "Hey, that is immutable, but there is a problem." And the problem is this is close to where you are, and you can access it very easily. But unfortunately, though, my system that I'm using right now is way over here. And if it wants the data, it's got

to hop through the network and access it. So, there's a latency to get to the object. And you say, "Is there a way you can help me with that latency so it doesn't really cost me that network delay to go get it?" And you say, "Sure. You want a performance improvement? So, we'll take that one and we'll simply make a duplication of it, right? So, we have

two instances of that and something I can keep nearby. So, now I have a local copy. We have cached it basically. But wait a minute. If I cache it and you modify this, that's going to be inconsistent, don't it? What do I do? Oh, don't worry about it. It's immutable. It's not going to change. So, the copy is very safe because a copy is not going to

change also. And the copy is always consistent with the original. And this is why what is immutable is is is very safe to share, but also it is safe to copy. This is one of the things that gives you advantage on both sides. You can either share it where it makes sense or copy it where it makes sense and it's very very safe to do so. So,

that is one of the benefits we get out of this in general. So, having said this, you say, "All right, that's all great, but I'm going to create a a central enterprise database." So, you're created a central enterprise database. So, in this particular case, your database is here and all the applications you have are referring to that database. What does it mean to have a shared database?

An enterprise database, a shared database, is is equal to essentially lack of encapsulation. So, this is unfortunately the reality. If you share a database, what happens? The If you share a database, you lost on encapsulation, right? How is it? Well, my the system depends on that schema, this depends on that schema, a third one depends on the schema, and all of them depend on the schema. Now,

if I modify the schema, every one of them falls apart. Why? Because every one of them have exposed their their internal to be visible to other systems. So, a shared database is lack of encapsulation. Now, this is this has consequences, right? So, what are the consequences? The consequence is you have intertwined, you have coupled in this particular case, whether you like it or not. And as a

result, it becomes really hard to evolve systems. So, this is something for you to think about. Now, if you don't want this kind of a mess, there are a few things you want to think So, in a system like this, uh if you have a shared database, if somebody says, "My system needs a change." and as a result, you modify the schema, you pretty much blew every

other system out of the water. If those system are the supposed to be somewhat independent of each other, you are causing tension between the teams that maintain this application because your change affects them. So, what's going to happen in this case? Either you make a change and you made them break, that's fragile, or you say, if I make a change, that's going to affect them and they're

going to yell at me. I don't want to take that word, so I'm going to be reluctant. I'm not going to change it. I have become rigid. So, either it leads to fragility or it leads to rigidity, unfortunately, in this case. So, this is one of the consequences where there's that trade-off between the two that we need to be careful about. But, this also becomes more problematic.

So, lack of encapsulation is equal to You say, "Okay, Venkat, you lost encapsulation, so what's the big deal, right?" What is the big deal? Encapsulation is low, so that means it's going to be a little bit more difficult. Why should I care? Well, let's think about this for a minute. I have an application here and that's using this database. I have another application here that's using the

same database and a third application using the same database. Now, your business analyst comes to you and says, "Hey, we need to make a change. We have a change in the tax law. We have to compute the tax not only based on these values, but we have to compute tax based on this other thing as well." And you are like, "Sure, if that is the business requirement

and that's a change, we will accommodate it." And what does your business say? "I know, thank you. I was counting on it. I I really appreciate you guys can do this quickly. When can you have it?" And what does your team say? "Oh, you know what? Uh we can have it, you know, not not not too bad. We can do it." Oh, where when will you have

it? Uh let's say in about 7 months. And your business freaks out, right? 7 months? I thought you could get this done next week. And you're like, "Oh, no, no, no, no. You don't understand software development, do you? This is going to happen soon. Well, why not? Well, for your feature change, we have to introduce this new table in the schema, and we have to move the

data from here to that one, and split this column into two representation. And for us to do this, we have to first come up with how it what the change in the database is going to be. Then come up with the change in the code. Then go to these other teams and say, "We are going to make this change. Are you ready for it? When can you

be ready? Is this change acceptable?" So, we got to coordinate with all these teams, and by the time we are done with this, you would have forgotten why you needed it. So, the point is we're going to be very, very, very slow. So, what does lack of encapsulation mean? Lack of encapsulation means low a very low, you could say, agility, right? So, lack of encapsulation leads to

low agility. You are not able to make the changes as soon as you are able to because you got to wait and coordinate with something else. That is one of the problems. And and in this case, your entire focus is on stability and not on agility. What are you worried about? You're worried about somebody is going to make a change, and that's going to entirely break all

the applications. So, what do you tell the developers? Please don't mess up. If you change anything, you're going to be in trouble. So, we are threatening people saying, "That schema is sacred. We're going to put a moat around it, run crocodiles in the water, and if you try to change it, it will bite you, right?" And and so, we protect this heavily because if they modify it,

a lot of applications will break. That's too expensive. So in the process, we are working hard to keep things stable and we don't have the ability to change, we lower the agility. Now the question is, what if your business really needs lot more agility than you are able to provide? This is called architectural misalignment. When your architecture is misaligned, there's a tension. You do things in a

certain way and the business wants something else and we are in a you know in fight all the time. They want it, we cannot give it. We want to do something and that's not working for them. Why? There's the architectural misalignment. We cannot move at the pace at which our business wants to move because we've not accommodated those in our system. So then the question is, how

what can we do to improve this situation? Where does this really stem from in general? Well, there are these three things we talked about, but services, packages, modules, a few other things we normally consider. And in terms of this, uh generally you have aggregates, uh factories, repositories. Aggregates generally are the root of objects that lead to these entities. On the other hand, factories are the ones that

create these entities. Repositories are the ones that store the entity. So think about it this way. A factory comes at birth. Once the object is born, the factory is done, right? It does It's not involved. But a repository is there for the rest of the life cycle of the object. As you update it, as you change it, as you store it, all the way up to time

you may delete it potentially. So this brings us to how do we model this and how are we going to implement it? So, this comes us to two two ways to model. So, one is a model and the other is really called the distributed model. So, essentially a universal model versus a distributed model is something we need to really think about. So, what in the world is

a universal data model? A universal model as the name alludes to is a single occurrence of that particular definition. It's a common database, a single schema that you maintain. And that representation is universal because all the applications rely on that one single representation. Now, there's always pros and cons to what we do. Excuse me. So, in this case, what are the benefits the universal model gives you?

The first one is dry, right? So, how does it give you dry? The data is in one place. That's where it is. You're saying, here's a person, they have an address and phone number and email and other contact information. Where is it located? Right there. It's in that database and that's what all the applications are using. You have not duplicated the data. The data is in one

place and one place only. So, it is dry. The second thing is that becomes your In the in this case, truth you know our information. So, it's a single source of truth or a single source of implement uh information. You are able to reuse this really well. That's one of the nice things, right? You're able to reuse it, and you can say, "Hey, I can have this

library, and I can use that library to talk to this data, but all the things can use this particular interface, and so it has a high level of reuse, which is really good." But, there's another benefit. It also gives you a strict consistency, right? So, it has a strict consistency. So, how is that? It's because the minute you change the data here, it becomes visible everywhere. So,

you're not worried about, "Am I looking at a stale piece of data, right?" No, because I make a change, and boom, you see the change on your side. So, there's a But, before we move forward, this is one of the things we have to be careful as programmers. As a programmer, if you believe strict consistency is very important, you are going to work towards providing One of

the things I often ask myself and others to remember is this, if you force yourselves to get by getting that, what else did you lose? What else you cannot have? That's a question we need to understand. That's a question we need to ask. what it boils down to is a decision you make reduces options for a few other things. So, in this case, we said, "I want

strict consistency." Well, guess what? That may have impact on availability. really dealing with network partitions. So, these could be having effect on what you can do. So, essentially in this case, that's a downside having strict consistency may not help you a lot. But that also goes to some other things. Uh lack of encapsulation. So, notice this is not a plus. This is a minus. So, you're losing

out on the encapsulation. You end up with low encapsulation in this particular case. You you lose out on it. Not only that, you can have less availability. Why is that? If that were to have a crash, you are not going to be able to do much. Your availability goes down. It's a less availability. And also, it has increased uh complexity. So, why is it increased complexity? You

probably have to make sure that all the things are working together properly and not running into each other, having race conditions. So, what do you do? You lock over here. And then you wait for the lock to be released, and then you make the update, you unlock it, then this can come and access the data. That's a more complexity into your system, whether you like it or

not. But not only is it increased complexity, it is also lack of cohesion because the cohesion because your system now can know more than it needs to know because that's exposing all the information across systems. So, your system is going to be affected when any of the things are modified. That's basically not good separation of concern, lack of cohesion as well. This also leads to one other

problem. Uh are in a V-shaped, you could say, V-shaped, if you will, uh a scale a scalability. So, you are in a V-shaped scalability. What does that mean? As you can see, the V is like a bottleneck. You you are instance one and you're instance two. But what do these two instances do? Those two go to the same database to access. So, even though the instances are

different, that gives you scalability at the application level, there is no scalability at the instance level. Sorry, at the database level. Why? The database is the same and they are both accessing it, this can only serve so many requests at the same time, that affects the scalability. Now, you may say, "Hey, in my system, I've got all these libraries that talk to the database. What's the big

deal?" But they all talk to the same database, right? So, that becomes the bottleneck eventually in this particular case. Something to think about. So, those are the consequences of a universal uh model. Well, what is the opposite? What can we do instead? This brings us to what's called a distributed model. The first benefit is higher So, essentially, you have an higher, let's say, in this case, higher

That's the first benefit, right? When you have a distributed model, what does a distributed model mean? A distributed model means I have my application, I have my database, my database contains the data I'm going to use. Here is another application, it's got its database that contains data it's going to use, so that data is kept separate. Benefit, this application can decide how it represents data. This application

can decide how it represents its data. This one says, "I'm going to store in the database a month as a column, a a day as a column, year as a column." Well, good luck. You got three columns to represent the date of an insurance policy. What about here? I have an insurance policy date, but I have one column which contains the entire date. So, this is something

you do in how you separate and implement it. That's your business. So, it gives you this power of encapsulation really well. You also get uh business agility. So, you get high business agility. So, my business can say, "I want to change this." And you're like, "No problem. We'll have this for you in 2 weeks." How so? Because uh we don't have to depend on anybody else for

this change, because we own this entire thing and the visibility is zero outside, right? So, so that's basically the benefit. High cohesion. So, that can give you high cohesion because you are really dealing with So, you're dealing with the data that you need on your side, and you can represent it any way we you want and without affecting other things as well. This also has less complexity.

You locally deal with the data format the way you need, and you don't have to lock and unlock all those problems really go away. So, that is another benefit of this approach is that you got better agility, but you also have less complexity as well. And of course, you have a bit more of the benefit in here. This also gives you that it's more scalable as well.

So, more scalable in this particular case, uh you know, write uh down to the uh the uh database. How so? Because your instances can access a database that is you know, specific to that instance, and it becomes easier to access it, more scalable. So, that is another benefit, also. But, in this case, you also have better uh availability. How is that? So, availability Uh why is it

better availability? Because if one part of the system goes down, other parts of the system can function, because the other parts of the system can talk to their own database and can be available while some part of the systems are broken down. This is kind of like, you know, you may be in a building, but they may close a uh floor or a group of rooms and

say, "We are cleaning this, so you cannot get in here, but the rest of the building is still available." So, so you're not shutting everybody down, there are parts that are still available, and you can make use of However, there are also disadvantages, as we as we know. The first is it provides eventual consistency. So, this is one of the things to keep in mind. It provides

eventual consistency. So, what is eventual consistency? If one system makes a change, the other system may not see it until this system either passes a message or that system sends a message to get the update. So, the data has to move across machines, and so that becomes an eventual consistency. Oh, by the way, eventual consistency doesn't mean some other day, right? Eventual consistency doesn't mean some other

time in the future distant future. Usually, eventual consistency is fractions of seconds. This is like the other day I was joking, I flew from uh Copenhagen from Frankfurt to Copenhagen and I land and after landing, I get a notification for my gate for departure. I said, "This is a wrong way of doing eventual consistency, right?" I've already taken the flight and arrived, it was to tell me

what the departure gate is, that's when the notification is arriving. So, that's that's too much of a delay, that's not what eventual consistency is. The eventual consistency is typically very very small fractions of seconds normally before the other side sees, but the point still is it is not strict, it's not instantaneous, that is something to think about. It also has an a problem with dry. Why? Because

the same data is in multiple places. Sure, it could be in different format, but it's in different Where is this person's information? It's here, but it's there as well potentially. So, that's a duplication, so it it violates the dry in this particular case. It is also hard to reuse, it's a negative. So, reusability is low, why? Because each part is taking care of its own stuff so

that they can reduce the dependency and increase the agility. And single source of truth uh in this case, you cannot really point to anything and say that it's a single source source of truth and we are celebrating it, right? So, this is another disadvantage. So, if you look at it, the things that were a plus over here uh typically made lean towards a minus over here and

a few minuses over here may end up being pluses over here as well, that's your trade-off. So, in this case, you want to be able to decide whether a universal model is better for you or a distributed model is better for you, that's a choice you have to make. So, uh how can we then proceed to implement knowing that there are these pros and cons and how

are we going to work with it? So, essentially in this case, there are these benefits of these two models and a uniform universal model, especially in a large application, leads to issues uh in in general. So, different modules have different expectations, needs, and constraints and and as a result, they collide with each other, make it harder to maintain. So, a unified data model, in general, is more

expensive and more time-consuming uh to maintain in the long run. So, the question is, where should a patient information be in a hospital? You can create a centralized database, put all the patient information in it, and you can have different systems that talk to the database to get the data. Now, the the benefit, one place where all the data is. A disadvantage, these all have to talk

to this. You modify one, everything else is going to break because they're all depending on the schema, there's a lack of encapsulation, right? So, that is one of the disadvan- disadvantages of this. So, in this case, a good modularization requires really good separation of concern and clear boundaries between these. And models should be defined clearly, deliberately, internally. So, you want to be able to say this is

my definition, I don't want to be forced by your definition, which is probably much broader. And and so, we really want to rely on cohesion, high cohesion, and and to have well-defined interfaces for communication. So, let's think about What are the things I want to favor more? This is something we need to keep in mind. We are not saying I don't care about dry. You're not saying

I'm going to go to work with vengeance and violate dry. That's not your goal. You are saying these are important but I'm going to raise the importance of this without disregarding this entirely. So, we'll start with the emphasis these two have the same expectation, but I'm going to put more emphasis on not as much on dry. You're like, why? Because I care about business agility more than

other factors in my application. So, that's why you're going to vary these things as well. uh, given this, share share relevant subset of the data instead of the common model. So, what you are saying is we're not going to share the database but instead, we're going to keep the data in multiple locations and we will define an through which we will do messaging. So, I can message

you my data. You can receive the message and how you store it internally is your business. I don't know. I don't care. And you can take the data, send it over a message to me, and I will store it on my side. How I store the information is my business. You shouldn't care. You shouldn't ask. So, that is a separation of keeping these two isolated from each

other. Now, what are some of the cons of this model? It's possible you may have a divergent representation of the data and you should be, you know, comfortable with There's a communication overhead. When you change something, it's not like I change the database, I'm done. Well, I've got to send this over a wire and send you a message, which you can receive and process. So, that's going

to be a bit of a communication overhead. And needs translation between communicating communication across boundaries. Remember that famous Mars rover that crashed on Mars? Why? Because one set of people thought it was miles, the other set of people thought it was kilometers, right? So, that's something you want to avoid. So, in this case, this needs a translation between communication. So, when I'm sending you some information, I

may have to not only tell you the value, but the unit of measure. So, if I say, "Hey, here is 10 lbs for you in in weight." And you're going to say, "Well, 10 lbs, what does that mean in kilograms, right?" And you need to do the translation of it to store it on your side. Maybe you're storing in in in in metric units, maybe I am

storing it in English unit imperial units. Well, we may have to do the translation back and forth. I'm going to give it to you in pounds, but you store them in kilograms. Or you are storing in a kilograms and send it to me, I've got to store that in in in pounds. So, we have to really convert it. That becomes part of the expectations as well. We

need to communicate this across boundaries and keep it consistent. It may seem like it's inefficient, right? Because, boy, you are sending this across these systems that could be not very effective and seems rather inefficient on the outset. But, on the other hand, you can say that the distributor system much better results to communicate. But, you know, unified model is plagued with these greater problems. But, in order

to achieve this, there are a few things you need to consider. One of them is the bounded context. So, the bounded context basically says, yes, this information is out there, but what I am going to represent is the only thing I care about. So, let's think of this for a minute. If I say car, what is what comes to mind when I say a car? You can

say, oh, a car. I want to know the model of the car, the make of the car, the color of the car. I want to know if the year, right, the color was the car was made. I want to know about services that have happened on the about accidents this car may have been involved in. I want to know who the owner of the car is. I

want to know if the car is still in loan or it's been paid off. You can see how much of information can go to. Excuse me, bounded context. You are saying, okay, that's all about but I care only this information. I care about the model, the make, the year, and that's all I care about. I don't need to know about all the services, when the car was

serviced, if it has been in an accident. Another part of the system may say, I only want to know when the car has been insured and that if the insurance policy is effective. I don't care about anything else. So, the beauty of this is each one can have a separate representation, and that's really decided by the bounded context. And in this case, of course, we talk about

the and the domain modeling within the bounded context. So, the moral of the story here is that there are pros and cons for each of the approaches, and it's for us to decide which one of them makes really good sense, and based on that, uh provide what actually is helpful to the business. So, think and ask the question, what does the business actually need? It's not about

our convenience, It's actually about what can we deliver. That's really the purpose of an architecture is to enable that for you. Hope that was useful. >> [music]