Beyond Code: The Quality Attributes Every System Must Have

In my previous article, I discussed the fundamentals of software architecture and how architecture shapes the structure of a system.

But architecture is not only about components and services.

What really determines whether a system succeeds in production is something else: Quality Attributes.

These attributes define how well a system behaves under real-world conditions.

For example:

• How fast does it respond?
• Can it handle sudden traffic spikes?
• What happens when something fails?
• How reliable is the system for users?

With the rise of AI coding assistants like GitHub Copilot and Cursor AI Editor, generating code has become incredibly easy. But designing systems that perform well, scale properly, and recover from failures still requires thoughtful architectural decisions.

Let’s look at some of the most important quality attributes every engineer should understand.

Performance

Performance is about how quickly and efficiently a system responds to requests. Two common metrics help us measure this:

Response Time

This is the time a system takes to respond to a request. For example, imagine searching for a product on an e-commerce website. If results appear in 200 milliseconds, the experience feels smooth. If it takes 3–4 seconds, users quickly lose patience.

Throughput

Throughput measures how many requests a system can handle within a given time. For instance, a payment service might process thousands of transactions per second during peak shopping hours. A well-designed architecture ensures the system maintains good response time even when throughput increases.

Scalability

Scalability refers to the system’s ability to handle growth without breaking down. Growth can happen in different ways, and so can scaling.

Vertical Scalability (Scaling Up)

This means increasing the capacity of a single machine. For example:

• Adding more RAM
• Increasing CPU cores
• Using a more powerful server

While simple, this approach eventually hits hardware limits.

Horizontal Scalability (Scaling Out)

Instead of making one machine bigger, we add more machines.

Traffic is distributed across multiple servers using load balancers. This is the approach most modern cloud systems use, especially when running on platforms like Kubernetes.

Team Scalability

Scalability is not only about infrastructure — it also applies to teams. If the system is tightly coupled, adding more developers can actually slow things down. Architectures such as microservices allow different teams to work independently. For example:

• One team manages payments
• Another manages orders
• Another manages notifications

This allows organizations to grow engineering teams without creating bottlenecks.

Availability

Availability measures how often a system is operational and accessible to users. You may have seen availability expressed using “nines”.

Large platforms like Amazon and Google often aim for extremely high availability because even a few minutes of downtime can impact millions of users.

| Availability         | Downtime per Year | Downtime per Month | Downtime per Week |
|----------------------|------------------ |--------------------|-------------------|
| 99% (Two Nines)      | ~3.65 days        | ~7.2 hours         | ~1.68 hours       |
| 99.9% (Three Nines)  | ~8.76 hours       | ~43.8 minutes      | ~10.1 minutes     |
| 99.99% (Four Nines)  | ~52.6 minutes     | ~4.38 minutes      | ~1.01 minutes     |
| 99.999% (Five Nines) | ~5.26 minutes     | ~26.3 seconds      | ~6 seconds        |
| 99.9999% (Six Nines) | ~31.5 seconds     | ~2.6 seconds       | ~0.6 seconds      |

Two important metrics related to availability are: MTBF (Mean Time Between Failures) How long a system runs before a failure occurs. MTTR (Mean Time To Recovery) How quickly the system recovers after a failure.

The goal of resilient systems is not to eliminate failures completely — that’s unrealistic. Instead, the goal is to recover from failures as quickly as possible.

Fault Tolerance

Failures are inevitable in distributed systems. Servers crash. Networks fail. Dependencies go down. Fault tolerance ensures that the system continues functioning even when something breaks. There are three key approaches.

Failure Prevention

Reducing the chance of failures. Examples include:

• Input validation
• Rate limiting
• Circuit breakers

Libraries like Resilience4j help implement these patterns.

Failure Detection and Isolation

When something fails, the system should detect it quickly and prevent the failure from spreading. For example, if a recommendation service fails in an e-commerce platform, the product catalog should still load. Monitoring tools like Prometheus help detect such issues.

Recovery

Once a failure happens, the system should recover automatically. Examples include:

• Restarting failed services
• Switching to backup systems
• Retrying failed operations

Modern orchestration platforms like Kubernetes automate much of this recovery process.

SLA, SLO, and SLI

Engineering teams often define system reliability using SLA, SLO, and SLI. These terms are closely related but represent different things.

Service Level Indicator (SLI)

An SLI is a measurable metric. Examples include:

• API latency
• Error rate
• Availability percentage

Example: “95% of API requests respond within 200 ms.”

Service Level Objective (SLO)

An SLO is the target value for an SLI. Example: “99.9% of requests should succeed.” This represents the internal reliability goal for the engineering team.

Service Level Agreement (SLA)

An SLA is a formal commitment made to customers. For example: “A service guarantees 99.9% uptime per month.” If the provider fails to meet this commitment, compensation may apply. Cloud providers like Google Cloud and Amazon Web Services publish SLAs for their services.

Why This Matters Even More in the AI Era

AI can generate working code in seconds. But AI does not automatically design systems that:

• scale properly
• handle failures gracefully
• meet strict availability targets
• maintain performance under heavy load

Without architectural guidance, AI-generated code may work perfectly in development but struggle in production. That’s why understanding quality attributes is becoming more important than ever. Developers need to guide AI tools with the right architectural constraints and system goals.