Key Principles

[00:00:00]
>> Erik Reinert: So, we talked about these a little bit in the earlier slides. But now we're gonna actually go into deeper detail around the, I like to call the main four principles of architecture designs, which is, modularity, scalability, robustness, and flexibility. Now, you have to think about each of these individually, you can't just kind of Kind of try and lump everything into one.

[00:00:21]
You wanna be able to look at your architecture and say, okay, is it modular enough? Am I reusing things in the right place? Are things coupled the right way? For scalability, you wanna be able to understand things like, how much traffic are we gonna have so forth and so on.

[00:00:37]
Robustness, is the system dependable? Right, are we dealing with problems every day? If you build an architecture and you're dealing problems every day, it might not be very robust as well as flexibility, being able to support future changes and things like that. So, let's get into modularity first, right?

[00:00:57]
Each component of the system should have a specific task. This is probably the easiest way I can describe modularity for a backend architecture. Maybe you only have one component, that's fine, as long as it solves the one specific task that you need it to. We're not saying that again, this has to be a crazy distributed platform, it's just, you have to be able to say this component does this, and why does it do this.

[00:01:24]
And that will help you a lot with your argument, communication, learning, and hopefully it'll get to a point where it becomes easier to understand and people can say, okay, well, this component's over here. Okay, this component's over here. I could just use this. And hopefully, you'll have good naming conventions around it.

[00:01:47]
For example, I do know some companies name their internal services all sorts of crazy things. I would shy away from that, I know it can be fun to call your system Pokemon names or something, I don't know. But realistically, if they don't understand what the modules are, it's a lot harder to build on top of them, there's more communication needed.

[00:02:11]
We call that friction basically, there's more friction added. Scalability, so the system should be designed to handle growth of traffic, right? So after we talk about modularity, we wanna be able to scale those modules individually, right? Is there a certain part of your system that takes more traffic than other?

[00:02:32]
A good example of that is I'm currently working on building a content creator tools platform, and one of the things that we do is that we process chat messages from Twitch and other streaming platforms. And for every single message that comes into our system, there may be three or four or five other calls lower down in the system that you need to be able to consider.

[00:02:56]
And that's a big part of it, is making sure that you don't have any Bottlenecks, anything that will potentially impact system performance, and things of that nature. You wanna be able to make sure that every module or every component can scale, basically.
>> Erik Reinert: Robustness, again, as I said before, the system should be able to handle unexpected situations or errors or things like that.

[00:03:23]
And I think actually this is a really big thing that a lot of people fail at. And the reason why I say that is because, more often than not, I noticed a lot of companies do not spend time in proper error handling. Like, how many of you at companies today have errors that you have no idea what they are or what they do, right?

[00:03:45]
What is this error code? Why did it give me a 404? I didn't expect a 404, right? What is Unknown Error, [LAUGH] right? Like, that's not robust, that doesn't help you scale a system, right? So it is a really good consideration to think about, when you connect two different components together, how's it gonna handle errors, right?

[00:04:08]
How's it gonna receive those errors? How's it gonna respond to those errors? Another big thing that I see a lot is the code itself doesn't know how to handle the specific message and then it just crashes, right? Being able to think about that, think about what could potentially break in your architectures is really important.

[00:04:33]
And I would recommend, especially around error handling and things like that, build your own language, right? Frontend users don't care about your error codes, you don't need to show those in the frontend, right? But if you can show better errors to your systems so that they can react accordingly, that just makes it easier for those systems to heal themselves or be able to continue with whatever they're trying to do.

[00:05:00]
>> Erik Reinert: And this one, now, this one is very challenging, flexibility, right? I deal with this a lot and I definitely don't think there's a perfect science to this either. What does flexibility mean? It really means that the system should be designed to accommodate changes or future features, right?

[00:05:24]
This kinda depends on how much your company wants to invest into this, right? But the main goal here, and I think a lot of us have dealt with this too, is you don't wanna be in a scenario where you have to take one step or two steps back to take one step forward.

[00:05:38]
And I've worked with this a lot in the past, where I've gone to a specific system and then I've been like, okay, we wanna change this. And they're like, well, to do that, we gotta refactor this and then move this around and move that around, and that really isn't a flexible system.

[00:05:57]
That means that that system was potentially designed to solve one problem, one problem only, but it wasn't considering the potential changes of the architecture. Again, maybe one system doesn't have the error handling of another system, and things like that, yeah.
>> Speaker 2: Someone online said every mistake that you've mentioned so far, there's a company that this person worked at.

[00:06:19]
>> [LAUGH]
>> Speaker 2: Basically, that's why they quit, was cuz of all of this.
>> Erik Reinert: Yeah.
>> Speaker 2: And then Amber was asking about, so you mean loggers, like, showing better errors in the system?
>> Erik Reinert: Yeah, well, it can literally be, having responses come back in a structured format of your choosing, right?

[00:06:38]
I've worked at companies and I actually like this approach, where they create their own error codes, right? Where you sure you have response codes of 200, 300, 400, whatever, but then you can create like enums that are in like a shared library. And then all of your systems use those shared enums, right?

[00:06:57]
And then, instead of having like, okay, how many of you guys have had to do a contains error message to be able to respond to something, right? That's not a good approach. If that changes in the future, then you have to now go back and update all your contains in your functional logic, right?

[00:07:17]
A much better system would be to design your own, again, language around your errors. It can be error codes of your own, for example, I'm sure a lot of us have either played a video game or been on a website and it's like, error code 1064. Well, that doesn't mean anything to anything but the company, right?

[00:07:36]
But at the same time, the company can immediately understand the problem all the way down to customer support, right? Think about that, right? Say you have a really weird error pop up in a frontend and somebody has to call in and solve or wanna know like, why am I just getting this weird internal server error?

[00:07:53]
But if the customer support can say, well, what's the code? They can immediately look that up and be able to trace that error a lot quicker for you. And so, anything like that, even logging as well, right, having good logs, don't log everything, right? A big thing that I see a lot as well at companies is they log everything, and then they wonder why their cloud costs are so high.

[00:08:15]
[LAUGH] You're logging everything, right? Having really good structured logging, only logging when you need to, right? Sometimes you don't need all of those logs, so don't worry about them. So yeah, again, flexibility is really important with regards to all these things, because if you're building a flexible architecture, you may have other principles that already exist that even make it more flexible, right?

[00:08:36]
Think about it like this, think about having 50 services and then having asked yourself the question, how do we handle errors for all these services, right? If you have one standard library that does all that for you, then you can easily have everything in that standard library, all the services can use that library.

[00:08:52]
And now you're structured, you don't have to worry so much about, well, what happens if we add a new error in the future? How do we handle that, right? All those standardizations have already kind of been put in place, and it can help a lot with the flexibility of newer systems as well.