Lesson Description
The "Non-Functional Requirements Exercise" Lesson is part of the full, Backend System Design course featured in this preview video. Here's what you'd learn in this lesson:
Jem instructs students to consider non-functional requirements for a banking app, focusing on system quality beyond user functions. He guides them to address security, performance, observability, encryption, audit trails, availability, and compliance.
Transcript from the "Non-Functional Requirements Exercise" Lesson
[00:00:00]
>> Jem Young: I can tell the look, we'll just do the banking one as an independent exercise because I want to see how you all do. Then we'll do the URL shortening one together. Non-functional requirements for our banking app. Different way of thinking about the same problem, different level of thinking. Now we're thinking about the quality of our system, not the user functions necessarily, but how do we support all those aspects we're trying to, how do we figure out what's important, security, performance, observability.
[00:00:33]
How do we get that? And the only way we know is one, we have some intuition about, it's a banking app that tells us something. But also we ask the questions. So, what questions did you write down, examples that would give you some idea of the kind of scope of non-functional requirements? How many transactions per user? That's a great one. How often does a user have to do a write through the app like transferring money or paying something?
[00:01:11]
Well, I can say that. Can we say, well. I was going to say, what is the rate of transactions per user, that's what we asked earlier. Yeah, mostly I was just splitting the read from the write, because I'm assuming it's a little read heavy. Yeah, how many years does the transaction record need to be kept for the user? How frequent and what should be the response time?
[00:01:50]
Say what is the minimum latency? Is the allowed downtime? Oh, are you thinking like planned downtime? In terms of like maintenance, if we're like we said earlier, trying to go for more consistent non requirement, then we would want to plan maintenance downtime for it. So something like, like what is our availability target or something like that. You probably also have to have a definition of what you do for the planned downtime.
[00:02:30]
I'm trying to think if that's a functional or nonfunctional requirement. That might be functional, but it impacts the user. Yeah, I like your thinking, because my bank is just like, sorry, it sucks to be you. They don't really give you a choice, but they do tell you it's happening. Yeah, but you know, I'm kind of a captive user. I don't have a choice. They have my money, so what am I going to do?
[00:03:04]
Does this traffic increase or decrease throughout the week, day, week, month, year? We'll say how consistent or the traffic is traffic patterns. Probably a better way to put that. Are they, is traffic consistent over time? Just because it goes up and down doesn't mean it's not consistent, just means it consistently goes up and down. That's fine. What are the durability requirements of the data like how do we need to have backup set for obviously this is very sensitive information, so replication.
[00:03:47]
Yeah, something like, how frequently do we back up data or how do you check your backups? Another common mistake people make, we have backups, they might check on them. Yeah, they're in that closet over there. That isn't, that tape drive hasn't been running in 2 years, so. How say how frequently or how long does it take to restore a backup? How long or, yeah, the maximum allowed time, I guess.
[00:04:35]
That one I might roll into availability because that's really what we're talking about, that is the same, I think. But I'd say the frequency of backup data is an important question, especially when we talk about like database sharding and replication and how do we recover from that? Where are the majority of our users physically located? Oh, that's a good one. That's a good one, make it sound fancy, what is the geolocation of most of.
[00:05:12]
Would this get into nonfunctional when you think about like government regulations based on where you are. What are the I don't know if it applies to banking or not. It's a data process compliance, yeah, because how we hold that data sometimes matters. Sometimes the government doesn't care, but they generally care. But maybe they don't. It depends. Might be related, but are there audit requirements, like up the system back-end?
[00:05:45]
Great question. What are the audit requirements? So, is the previous one, is there a data process compliance to be aware of? That's nonfunctional because it doesn't directly affect the user. Yeah, so a good example is, is there some mandated level of encryption that the transactions have to take over? What level of encryption do we need to provide on that data, if any?
[00:06:14]
That's all nonfunctional because the user won't see it, but we see it and we have to implement it. Protecting PII is probably the first I think of. And that might get into GDPR. Yeah, GDPR is a big one, very, very expensive compliance issue. I won't say more because I don't want to get sued. Yeah, some of the requirements there are very, very onerous, depending on what you're doing.
[00:06:44]
And then it breaks down by region too. So, one region in Europe will have very, very large requirements. Other regions will be like, whatever, don't care. Something to think about. And it does change. It does change. How adaptable is our system to changing compliance requirements. What's an example of nonfunctional, will it come up 4 or 5 of these. What can we say here?
[00:07:30]
Probably your uptime expectation or silly. Storm should have I don't know. Usually 99.9% or say 4 nines of availability. That is a good question. Cause that leads into how frequently do we need to back up our data to ensure that we're available some percentage of time, or is it OK to not be available? Yeah, who knows. It should be backed up daily. That's pretty flexible on the, that's a very wide window, but it's OK, you know, we put it down, they could be like, no, it needs to be backed up every 10 minutes.
[00:08:27]
What if we said the data. We'll say action data must be encrypted in transit and at rest. This is an interesting one because normally when we design a system, especially something with a microservice architecture, we're decrypting that traffic at the edge. Otherwise, when it comes to HTTPS, we'll talk about in a second, every single service has to decrypt that if they need to use that information.
[00:08:50]
So we decrypt it, so it makes it much faster to process through. We're not taking computational resources, decrypting every request, but if we have to encrypt that data in transit until it gets to the database and then we encrypt it again there. That's a very different requirement. That's expensive. What if I threw this one? Transaction can not be lost. I would go back to auditing, probably a pretty high level of auditing because you can recover lost data through logs in the worst case scenario.
[00:09:34]
And that could be a solution. We can have a very rigorous database and replication strategy, or we can say, hey, we can actually recover this from the logs, and that's our strategy we're going to apply. What was I going to say, I lost my train of thought. Should be audited audited by who did it and when, probably. A very important trait in a banking app. Your money's gone.
[00:10:07]
Who did it? Well, I don't know. It was the new guy over there. How do you know that? We don't know. Audit trails are very important in anything transactional. OK. We beat this one pretty good. You could add maybe alerts for observability. You had a any sort of like someone committed fraud or something like that. I don't know you necessarily know that. Yeah, I'm trying, that's a tricky one, because fraud detection, you can.
[00:10:42]
Is that functional or nonfunctional? Yeah, I see what you mean. That might be functional a bit. It's more of a business logic thing like how do you know this and that's where jumping back to functional, we were thinking purely of the user, but I'd say fraud detection is a functional requirement. But it's not, it doesn't impact the user or per se. That's why these are tricky.
[00:11:06]
How are y'all feeling about nonfunctional requirements? Different way of thinking about the system. What's important? Well, so I did have one more question. I wouldn't expect this to ever come up in an interview, but how, or I guess how common is it for accessibility concerns to come up when you're trying to do nonfunctional stuff? It depends. It's a good question to ask.
[00:11:33]
Does the system need to be accessible? In a functional requirement in there I put, what languages are we supporting? Does that matter? Sort of that level of detail. Generally, I'm going to say it doesn't come up as much, maybe if you're doing a front-end system design. That would come up because you designed very differently for the front-end there, but for we're talking about distributed systems, probably not as frequently.
Learn Straight from the Experts Who Shape the Modern Web
- 250+In-depth Courses
- Industry Leading Experts
- 24Learning Paths
- Live Interactive Workshops