Forem: Flik – Software Critical Dev

Why One Design Doesn’t Fit All: The Role of Quality Attributes

Flik – Software Critical Dev — Thu, 14 May 2026 08:16:47 +0000

Photo by Towfiqu barbhuiya on Unsplash

In our previous discussion, we broke down the difference between functional and non-functional requirements. To put it simply: if functional requirements answer the question, “What does the system do?” then non-functional requirements tackle something much more critical: “How does the system behave?”

In the world of system design, we call these behavioral traits Quality Attributes. Think of them as the report card we use to judge whether an architecture is actually good. We’re moving past just listing features; we’re talking about whether the system is fast, scalable, secure, observable, and—most importantly—cost-effective.

What Exactly is a Quality Attribute?

At its core, a quality attribute is an indicator of health. It helps us answer the anxieties of both engineering and business teams: “Is it laggy? Will it crash if our traffic 10x’s tomorrow? If one server goes down, does the whole app follow suit?”

People often confuse non-functional requirements with quality attributes. Here’s the easiest way to separate them: a Quality Attribute is the category (e.g., Performance), while a Non-functional Requirement is the specific target (e.g., “The search API must have a p95 latency under 500ms”). One is the label; the other is the measurable goal.

Why It Matters: One Feature, Two Very Different Worlds

Imagine two companies building a “Messaging” feature. On paper, they do the exact same thing. But look at the requirements behind the scenes:

System A: Built for a small group of users. Messages can be delayed by a few seconds, and message history isn’t a priority.
System B: Must deliver messages in milliseconds, handle millions of concurrent connections, and ensure zero data loss—even when users are offline.

Even though the “feature” is identical, the architecture will be worlds apart. System A might survive on a basic backend and a single database. System B? You’re looking at connection servers, durable storage, retry mechanisms, and a complex scaling strategy. This is why quality attributes are the true drivers of architectural decisions.

The Core Constraints That Actually Shape Your Design

When we sit down to review a design, we’re not just looking for “good code.” We’re looking for how the system handles specific constraints. These are the attributes that force you to change your architecture from a simple monolith to something more complex:

Scalability & Throughput: This is about more than just “handling growth.” It’s about how the system behaves under pressure. Can your database handle the write volume? Do you need to decouple services with a message queue to handle spikes?
Availability vs. Reliability: People use these interchangeably, but they aren’t the same. Availability is about the system being “up.” Reliability is about the system being “correct.”
Observability & Debuggability: If you can’t see what’s happening inside your production environment, your design is incomplete. You need structured metrics and tracing.
Cost & Resource Efficiency: Every architectural decision has a price tag. A senior engineer knows how to meet SLOs without wasting the company’s cloud budget.

Stop Using Vague Words

If I hear an engineer say “The system needs to be fast,” I immediately ask: “Define fast.”

Vague goals lead to bad designs. “Fast” means nothing. “p95 latency under 200ms” means everything. Why p95? Because the average (mean) is a lie—it hides the 5% of users who are having a terrible, slow experience. Make your attributes measurable, or don’t bother listing them at all.

The Bitter Truth: Everything is a Trade-off

System design is a zero-sum game. You want extreme security? Expect higher latency. You want 100% data consistency? Say goodbye to high availability during a network partition.

Your job isn’t to build the “perfect” system. It’s to find the least-bad set of trade-offs that fits your business goals.

What’s your "must-have" attribute?

I've found that teams often over-index on scalability while completely ignoring observability until something breaks in production.

I’m curious—which quality attribute do you think is most often neglected in early-stage designs? And what’s the most painful trade-off you’ve had to make recently? Let’s discuss in the comments!

System Design for Critical Systems: Thinking Before Failure Happens

Flik – Software Critical Dev — Thu, 14 May 2026 08:15:22 +0000

In a standard software environment, system design is usually a game of optimizing user growth and engagement. We obsess over things like: “How do we make the feed scroll faster?” or “Can we handle a million people buying sneakers at the exact same second?” It’s a blueprint for massive scalability and peak performance.

But when we talk about Critical Systems — where failure isn’t just a lost sale but a high-stakes risk to safety or national security — the definition changes. Here, system design isn’t about chasing the fastest scroll; it’s the process of building a structure that maintains integrity under pressure, uncertainty, and total failure.

At this stage, we don’t care about class names or specific syntax. We are looking at the system as a cohesive unit. We ask questions that matter long before the first line of code is written: What are the absolute constraints? How does data flow when a subsystem fails? How do we ensure human operators stay in control during a crisis?

Photo by Ibrahim Boran on Unsplash

Designing Beyond the “Happy Path”

Most consumer applications are designed around the “happy path” — the expected user journey when everything is working perfectly. In critical systems, we don’t have that luxury. We must design for the “unhappy path” from day one.

A critical system is judged not by how it behaves during normal operations, but by how it reacts when things go wrong. We have to anticipate scenarios that standard apps usually ignore:

What happens when two sensors provide conflicting data?
How does the system behave when the network is unstable or under attack?
How do we present complex information without overwhelming an operator who is under extreme stress?

Moving Beyond Technology-First Thinking

A common trap in engineering is starting with tools. We ask if we should use Kubernetes, Kafka, or a specific cloud provider. While these tools are powerful, they are not the solution to a critical mission.

In a critical environment, technology is only a vehicle for the requirements. In fact, unnecessary complexity is often a liability. It makes the system harder to test, harder to secure, and much harder to debug during a live incident. The goal is to make the system appropriate for its mission, which often means choosing a rugged, predictable architecture over a “shiny” but complex one.

The Core Pillars: Function and Quality

Every design starts with requirements, divided into two categories: Functional (what the system does) and Non-functional (how well it does it).

In critical systems, non-functional requirements like Reliability, Security, and Observability are not optional add-ons; they are the core of the design. A feature that works only under ideal conditions is a failure in a critical context. Whether it’s an early-warning system or a defense coordination platform, the ability to recover from partial failure and prevent unauthorized access is just as important as the feature itself.

System Design is a Game of Trade-offs

Here’s a hard truth every engineer must accept: There is no such thing as a perfect design. In the real world, every architectural decision is a trade-off. You simply cannot maximize everything at once.

When designing critical systems, we are constantly faced with dilemmas:

Automation vs. Oversight: Leaning heavily into automation might provide speed, but often costs direct human control.
Security vs. Latency: Robust security layers protect the system but almost certainly introduce latency.
Redundancy vs. Complexity: Redundancy ensures high availability but increases the complexity of the entire stack, making it harder to manage.

This is the real job of a senior engineer: Making these trade-offs explicit.

These choices shouldn’t happen by accident while someone is mid-code. They must be debated, reviewed, and stress-tested during the design phase. We need to be fully aware of what we are gaining and what we are giving up.

Conclusion

System design is not about making software look complex. It is about making the right decisions before complexity becomes dangerous.

System design for critical missions is about thinking through every possible failure before implementation begins. It’s about building a system that is not only functional but dependable and transparent.

In the world of critical systems, the best architecture isn’t the one that looks the most advanced — it’s the one that is most prepared for the reality of failure.

Let's Discuss!

I'm curious to hear from the community:

How do you handle the trade-off between system complexity and system reliability in your own projects?
What is one "unhappy path" scenario you wish you had accounted for earlier in a past design?

Let's chat in the comments!

Dropping my first post here. Thoughts? Let’s discuss!

Flik – Software Critical Dev — Thu, 14 May 2026 01:43:14 +0000

Flik – Software Critical Dev

May 14

I Used to Think System Design Diagrams Had to Look Cool. I Was Wrong

#lessonslearned #softwareengineering #architecture #diagrams

Comments

3 min read

I Used to Think System Design Diagrams Had to Look Cool. I Was Wrong

Flik – Software Critical Dev — Thu, 14 May 2026 01:33:55 +0000

I used to have a major problem with system design. Every time I sat down to map out a new architecture, my first thought wasn’t actually about how the system should function. Instead, I’d ask myself: “What diagram should I draw to make this look impressive?”

I’d obsess over the details. Should it be a high-level architecture map? A complex sequence diagram? Does it look “clean” enough? I wanted my work to look like those polished engineering blogs or high-end conference slides. Honestly, that pressure was paralyzing. I would stare at a blank canvas, drag a few boxes, delete them, move them around, and still feel like something was missing — not because the design was bad, but because I was treating the diagram like a piece of art rather than a technical tool.

Eventually, I realized I was wrong. A system design diagram doesn’t need to look “cool” first. It needs to make your thinking visible.

Example of a clear, functional diagram layout.

Diagrams Are Tools, Not Decorations

In the world of engineering, a diagram isn’t just a collection of boxes and arrows; it’s a communication device. It’s meant to answer the hard questions: Who is using the system? Where does the data live? What happens when traffic spikes? Where are the potential bottlenecks?

While you can explain an API flow in a long paragraph, a good diagram allows a team to grasp that flow almost instantly. The real value isn’t in the number of icons or the complexity of the lines — it’s in the clarity. If your team needs a 20-minute lecture just to understand what your diagram is trying to say, the diagram has failed.

The Problem with Starting with “What” Instead of “Why”

Most of us start by asking, “What diagram should I make?” But the better question is, “Why do I need to visualize this right now?”

This small shift changes your entire workflow. If you need to define the boundaries of your responsibility, start with a System Context Diagram. If you need to show the major building blocks, go for a High-Level Architecture. If the timing and order of events are what matter, use a Sequence Diagram. The form must follow the function. You don’t choose a diagram because it looks “professional”; you choose it because it’s the most efficient way to answer a specific question.

Visualizing the Trade-offs

System design is essentially the art of making trade-offs. Adding a cache might kill your latency, but it introduces the nightmare of stale data. Sharding a database helps you scale, but it makes your queries significantly more complex.

A great diagram makes these consequences visible. When you put a cache between an app service and a database, you aren’t just adding a box; you’re showing the team that we’ve traded simplicity for performance. It makes the discussion concrete. Once everyone is looking at the same picture, the conversation moves away from vague ideas and toward real-world problem-solving.

Don’t Put Everything in One Image

One of the biggest mistakes I used to make was trying to cram everything into a single “Master Diagram.” Users, mobile apps, databases, Kubernetes clusters, monitoring tools — all in one cluttered mess. It looked “pro” at a glance, but it was impossible to read.

Nowadays, I prefer a “zoom-in” approach. Start with the big picture — the system boundaries. Then, create smaller, separate diagrams for specific flows or infrastructure layers. A diagram is successful when it removes confusion, not when it adds more data points.

Final Thoughts

I’ve stopped trying to make my diagrams look like cloud provider marketing slides. A good diagram is simply one that helps your team move faster and make better decisions. It’s a tool for finding bottlenecks and aligning on architecture before a single line of code is written.

So, the next time you feel stuck in front of a blank canvas, forget about the icons and the aesthetics. Ask yourself: “What is the one thing I need people to understand right now?”

Start there. Your diagrams don’t need to be perfect; they just need to be clear. In system design, the best diagram isn’t the coolest one — it’s the one that makes the system easier to build.

I'm curious—what’s your go-to tool for quick architecture sketches? Do you prefer "whiteboard-style" tools or more formal modeling software? Let’s discuss in the comments!