DEV Community: Islem TRAIKIA

ARSMF — How to measure your non functional system performance

Islem TRAIKIA — Mon, 02 Jun 2025 11:22:22 +0000

In today’s fast-paced digital landscape, user satisfaction hinges not only on what your system does, but also on how it does it. Functional requirements ensure your application “works,” but non-functional requirements (NFRs) determine how well it works. To systematically assess these vital characteristics, we introduce the ARSMF framework:

Availability
Reliability
Scalability
Maintainability
Fault-Tolerance

This article will walk you through each pillar—defining it, explaining its importance, and detailing metrics and tools you can use to measure and improve your system’s non-functional performance.

Functional requirements (e.g., “the system shall allow users to register”) describe what your system does. NFRs describe how your system behaves under varying conditions:

User Expectations: Slow or erratic behavior leads to abandonment.
Business Impact: SLA breaches can incur penalties or lost revenue.
Operational Efficiency: Predictable performance reduces firefighting.

By quantifying non-functional attributes, teams can make data-driven decisions, prioritize engineering efforts, and maintain high service quality.

The ARSMF Framework Overview

1. Availability

Definition

Availability is the proportion of time your system is operational and accessible to users, often expressed as a percentage of total expected uptime.

Why It Matters

High availability underpins user trust and adherence to Service Level Agreements (SLAs). Even minutes of downtime can translate to significant revenue losses and reputational damage.

Key Metrics & Measurement

Uptime Percentage

Mean Time Between Failures (MTBF): Average operational time between failures.
Mean Time to Repair (MTTR): Average time to recover from failures.
Number of Incidents: Frequency of outages in a given period.

Tools & Techniques

Monitoring: Use solutions like Prometheus + Alertmanager or Datadog to track service health (HTTP checks, port availability).
Synthetic Testing: Simulate user interactions at regular intervals (e.g., with Pingdom or New Relic Synthetics) to detect downtime.

2. Reliability

Definition

Reliability measures the consistency of your system under normal conditions, ensuring it performs as expected without errors.

Why It Matters

Reliable systems minimize defects and failed transactions, delivering a consistent user experience and reducing operational overhead.

Key Metrics & Measurement

Error Rate

Transaction Success Rate: Percentage of transactions (e.g., payments, data writes) completed without errors.
System Crashes: Count of unhandled exceptions or process crashes.

Tools & Techniques

Log Analysis: Aggregate and analyze logs with the ELK Stack (Elasticsearch, Logstash, Kibana) or Splunk to spot error trends.
Distributed Tracing: Use OpenTelemetry or Jaeger to trace request flows and pinpoint failure points.
Chaos Engineering: Introduce controlled failure (with tools like Chaos Monkey) to validate resilience.

3. Scalability

Definition

Scalability is the system’s capacity to handle increased workload by adding resources (horizontal or vertical scaling) without compromising performance.

Why It Matters

As user load grows, your system must scale smoothly to maintain responsiveness and prevent bottlenecks that degrade UX.

Key Metrics & Measurement

Throughput: Transactions or requests processed per second (TPS/RPS).
Latency Under Load: 95th and 99th percentile response times during peak traffic.
Resource Utilization: CPU, memory, network, and I/O utilization across instances.

Tools & Techniques

Load Testing: Simulate traffic with JMeter, Gatling, or k6 to measure throughput and latency curves.
Autoscaling Policies: Configure infrastructure (e.g., Kubernetes HPA) to scale pods based on CPU/latency thresholds.
Capacity Planning: Model growth projections and identify scaling limits before they’re hit.

4. Maintainability

Definition

Maintainability gauges how easily your system’s codebase and infrastructure can be updated, fixed, or extended by your team.

Why It Matters

High maintainability accelerates feature delivery, reduces risk during updates, and ensures quick recovery from defects.

Key Metrics & Measurement

Mean Time to Repair (MTTR): Time from incident detection to resolution.
Deployment Frequency: How often you release changes to production.
Change Failure Rate: Proportion of deployments that cause incidents/fail tests.
Code Quality Metrics: Cyclomatic complexity, code coverage, and linting results.

Tools & Techniques

CI/CD Pipelines: Automate builds, tests, and deployments using Jenkins, GitHub Actions, or GitLab CI.
Static Analysis: Integrate SonarQube or CodeClimate to enforce code quality standards.
Modular Architecture: Design microservices or well-defined modules to isolate changes.

5. Fault-Tolerance

Definition

Fault-Tolerance is the ability of a system to continue operating correctly even when components fail, often by degrading gracefully.

Why It Matters

Complete prevention of failures is impossible; fault-tolerance ensures your system remains usable and data integrity is preserved during unexpected events.

Key Metrics & Measurement

Failover Success Rate: Percentage of failures that trigger successful failover.
Recovery Time Objective (RTO): Target time to recover after a failure.
Recovery Point Objective (RPO): Maximum data loss window you can tolerate.
Error Budgets: Accepted level of unreliability per sprint or month.

Tools & Techniques

Redundancy: Deploy redundant instances across availability zones or regions.
Circuit Breakers: Implement libraries like Hystrix or Resilience4j to isolate failing services.
Backup & Restore Testing: Regularly test backups and disaster recovery plans.

Conclusion

Non-functional performance is the backbone of a resilient, user-friendly system. By adopting the ARSMF framework—Availability, Reliability, Scalability, Maintainability, and Fault-Tolerance—you gain a comprehensive lens to measure, analyze, and improve your system’s behavior under real-world conditions. Start by establishing clear metrics, integrate continuous monitoring, and iterate relentlessly. Your users (and your business) will thank you.

The sacred commandments of Independent System Architecture (Illustrated by a project)

Islem TRAIKIA — Mon, 02 Jun 2025 11:03:41 +0000

Software architecture often struggles with tight coupling, dependency issues, and inflexible designs, making it difficult to scale and adapt. Independent System Architecture (ISA) principles provide a solution by promoting modularity, resilience, and independence between system components.

To illustrate these principles in a practical, real-world scenario, we present them as The Ten Commandments of ISA, each demonstrated through the Smart Parking System — a modern solution that helps drivers find, reserve, and pay for parking spaces efficiently.

1st Commandment: Thou Shalt divide The System Into Independent Modules

𓀃 Principle: A system must be composed of independent modules that interact only through defined interfaces. No module should rely on another’s internal implementation details.

🅿️ Smart Parking Example:

The Parking Availability Module (sensors and cameras) does not directly access the Payment Module’s database. Instead, it communicates through an API, ensuring independence.
This allows parking availability logic to evolve without breaking the payment system.

2nd Commandment: Thou Shalt Separate Macro & Micro Architecture

𓀃 Principle: Architectural decisions must be divided into two levels:

Macro Architecture: Rules that apply to all modules (e.g., using synchronous or asynchronous communication, Standardized documentation, Authentication, Integration testing…etc).
Micro Architecture: Decisions made within each module (e.g., programming language, database choice).

3rd Commandment: Thou Shalt Deploy Modules as Separate Processes or Containers

𓀃 Principle: Each module should be deployed as a separate process, container, or virtual machine to ensure isolation and independence.

🅿️ Smart Parking Example:

The Parking Availability Service, User Management, and Payment Processing run in separate Docker containers, ensuring that a failure in one service does not crash the entire system and why not zero downtime within Kubernetes cluster.

4th Commandment: Thou Shalt Standardize Integration and Communication

𓀃 Principle: The system must use a limited, standardized set of communication protocols, either synchronous (REST, gRPC) or asynchronous (Kafka, RabbitMQ).

🅿️ Smart Parking Example:

The system enforces RESTful APIs with JSON payloads for synchronous interactions.
Asynchronous event-driven communication is used for sensor updates (e.g., a Kafka event notifies when a parking spot is occupied).

5th Commandment: Thou Shalt Standardize Metadata

𓀃 Principle: Metadata such as authentication, traceability, and logging identifiers must be standardized across all modules.

🅿️ Smart Parking Example:

All API requests include a JWT token for authentication, ensuring that users don’t need to log in separately for different services.
Each request carries a trace ID, allowing the system to track transactions across microservices.

6th Commandment: Thou Shalt Give Each Module Its Own Continuous Delivery Pipeline

𓀃 Principle: Each module must have an independent CI/CD pipeline and be tested separately to ensure modular development.

🅿️ Smart Parking Example:

The Payment Service and Parking Sensor Service have separate CI/CD pipelines, allowing them to be updated or fixed independently.
Automated unit and integration tests ensure that new updates do not break existing functionality.

7th Commandment: Thou Shalt Standardize Operations

𓀃 Principle: Configuration, deployment, log analysis, tracing, monitoring, and alerting must be standardized to simplify management.

🅿️ Smart Parking Example:

All services use Kubernetes for deployment, Prometheus for monitoring, and ELK Stack for log analysis.
If a service fails, automated alerts notify DevOps teams to investigate.

8th Commandment: Thou Shalt Enforce Standards at the Interface Level

𓀃 Principle: System-wide standards must be enforced at the interface level, allowing flexibility inside each module.

🅿️ Smart Parking Example:

Every module must expose a RESTful API using JSON for data exchange. The backend team is free to use different programming languages (Python, Java, Node.js) inside their modules, as long as they comply with the API contract.

9th Commandment: Thou Shalt Make Modules Resilient

𓀃 Principle: Modules must handle failures gracefully, compensating for downtime and network issues.

🅿️ Smart Parking Example:

If the Payment Service is down, users can still reserve a parking spot, and payment retries are queued for later processing.
A circuit breaker pattern prevents repeated failures from overwhelming the system.

10th Commandment: Thou Shalt Allow Modules to Be Moved and Scaled

𓀃 Principle: Modules must be designed to be migrated across different environments without breaking.

🅿️ Smart Parking Example:

The Smart Parking System can be deployed on AWS, Google Cloud, or on-premise with minimal changes.
Auto-scaling ensures that when traffic increases, new instances of the Parking API are spun up automatically.

How could your next software project benefit from ISA principles? Let’s discuss in the comments! ☺️

The Simple Path to Domain-Driven Design: Understanding DDD in 4 Steps

Islem TRAIKIA — Mon, 02 Jun 2025 10:45:53 +0000

The modern architecture of software systems must be both flexible and robust. Enter Domain-Driven Design (DDD) — a powerful approach that emphasizes collaboration between technical and domain experts to create a shared understanding of the problem space.

If you’re planning to develop an e-commerce application, you might have plenty of ideas but struggle to structure them properly. While searching for guidance, you come across a thick book on DDD. But let’s be honest — you probably won’t read it at the office or on public transport. That’s why this article is for you. It summarizes the key DDD concepts in a clear and concise way.

In DDD, concepts like Bounded Contexts, Subdomains, and the overall Domain are crucial for structuring complex software systems. But how do these elements interact? Why is it important to understand their relationships? And how do they fit into modern architectural paradigms like microservices?

In this article, we will explore the definitions and roles of subdomains and bounded contexts, analyze how they communicate, and delve into data-sharing strategies. By the end, you’ll have a practical understanding of how to apply DDD principles to your own projects.

Step 1: What Are Domains and Subdomains ?
The Domain represents the overall business problem space your application is addressing. Within this domain, we separate Subdomains into three categories:

Core Domain : What makes your business unique and gives you a competitive advantage. This is where the majority of your effort should go.

Supporting Subdomains : Necessary but not unique to your business. Important, but you can put less effort into them.

Generic Subdomains : Commodity services that can often be outsourced or handled by third-party providers.

Subdomains in our E-Commerce App would be as following :

By structuring your subdomains clearly, you ensure that your development effort is focused on the most critical parts of the business.

Step 2: What Is a Bounded Context ?
A Bounded Context is a self-contained model with clear boundaries. Within a bounded context:

Terms, rules, and definitions apply consistently.
It encapsulates a specific part of the business logic.
Each bounded context is independent and does not leak concepts into others.

Eric Evans defines it as:
“A part of the software where particular terms, rules, and definitions apply consistently.”

Bounded Contexts in our E-Commerce App would be as following :

Each Bounded Context has its own database, business logic, and API to ensure loose coupling and scalability.

Step 3: How should Bounded Contexts communicate ?
Now that we have clear boundaries, we need to define how they interact. There are several key DDD strategic design patterns for managing these relationships:

Upstream & Downstream :
Upstream: A system that provides data to others.
Downstream: A system that depends on upstream services.
Example : The Payments Service (Upstream) processes transactions and updates Order Management (Downstream).

Customer/Supplier Pattern :
The Customer (Downstream) service relies on the Supplier (Upstream) and can negotiate changes.
Example: The Inventory System (Supplier) provides stock updates, and the E-commerce Website (Customer) depends on it.

Conformist Pattern :
The Customer must conform to the Supplier’s model, even if it’s not ideal.
Example: If using a 3rd-party Payment Provider, the E-commerce app must follow their API rules.

Separate Ways Pattern :
When two systems are too different, they remain separate.
Example: Product Reviews and Recommendation Systems may work independently.

So Bounded Contexts, in our E-Commerce App would communicate as following :

Step 4: Data Sharing & API Strategy
Now that we have a clear outline of our architecture, it’s important to define data sharing and communication strategies.

Anti-Corruption Layer (ACL) — Protecting Domain Models
When integrating with legacy or external systems, their data models may not match our domain. Instead of polluting our clean domain model, we introduce an Anti-Corruption Layer (ACL) as a translation layer.
Example: If our E-commerce app needs to integrate with a legacy Warehouse Management System, an ACL translates data before it enters our system.

Open Host Service (OHS) — Standardized APIs
When multiple external clients need access to a service, we should expose a standardized API.
Example: If multiple 3rd-party vendors need access to our Product Catalog, we should expose an API Gateway with well-defined contracts.

So using this concepts, our data sharing strategy would be implemented as following :

By structuring your software with DDD in mind, you ensure that your application remains scalable, maintainable, and aligned with the business needs.

Hope this article helped you understand DDD better. Have a nice day! 😊