I don’t like to use the word accountable when I’m talking in Portuguese. I try to make the word responsible do that work. But… in system and software design I see the word accountable important to make a point.
Usually every system starts with a big giant module that serves webrequests and delivers pages and APIs.
When we are growing, there are parts of the system that will need to respond faster and would need more characteristics of resilience.
Thinking of that, the first split I would run into a system already in production would be that. I split and then I can scale a specific part.
When doing that, the number of requests may also ask for asynchronous communication in some of the operations. We are going to understand the cost of some components. We are going to need a readonly data store. Or a cache system. That will help us to serve information, even knowing it can be a little bit outdated.
If you are building a system that works like a workflow, map it as a workflow, and you can use queues for producer/consumer structures to make sure you are doing the correct handoff.
If you break because of a non functional requirement, you will be fine. You have the data, you have the understanding of why you split a service in the first place. We are going to talk about requests per second, concurrent active users and metrics that will make us think about split, cache, async, background processing and things like that.
That’s just our systems growing and at the same time, we thinking about ways to not spend a lot of money (because that’s always an option if the money is not yours 🫠).
What we don’t want:
If you are modeling a system, think about how people will be able to maintain all those modules and think about structures that will enable troubleshooting when needed:
- Logs (make sure you have an unique ID where you can follow an item through your workflow)
- Audit (who changed what and when and where) so you can understand policies break or even some sort of fraud. And all those items I added up are sort of a journey, a process. Most systems are lacking some part of it, or need enhancements. That’s ok. The important thing is to understand that something is missing.
-- Daniel Wildt
P.S.: There are structures like 12 factor apps. There are performance and load tests, that will help you understand fragile parts of your system. Make use of them. Prepare for the worst. Understand when you are going to focus on some part of your system (considering you are a normal human + copilot team where you don’t have all the time you need).
Consider to follow, engage and sponsor my writing journey. Check my project at patreon.com/dwildt and become part of my special audience!
Top comments (0)