
## Concepts

The computer system's fault always be caused by instruments' and components' aging and inefficient. We trait their lifespan and present statistics information, conclude that every component in system have three stages: starting stage, normal working stage and aging stage.

At first starting stage, the component's working status may not stable, and has higher failure rate. At second stage it works normally and enters into stable, also has lower failure rate. But if it enters the third stage, system reliability will decrease due to aging factors. Its failure rate will re-increase again. This is also known as the _bathtub curve_. So the component should be kept in the second stage as much as possible.

The definition of reliability in computer systems refers to the probability of it operating normally from its initiation at time $t = 0$ to a specified time $t$. This probability can be represented by $R(t)$. The failure rate of a computer system refers to the proportion of components failing per unit time compared to the total number of components. It is denoted by $\lambda$. When $\lambda$ is constant, the relationship between reliability and failure rate can be expressed as

$$
R(t) = e^{-\lambda t}
$$

In computer systems, the time during which the system operates normally between two failure occurrences is termed the system's uptime. The average of all such uptime durations is referred to as the Mean Time Between Failures (MTBF). Its relationship with the failure rate is expressed as:

$$
MTBF = \frac{1}{\lambda}
$$

To express the maintainability of a computer, we commonly use the Mean Time to Repair (MTTR), which represents the efficiency of maintenance. It is the average duration from the occurrence of a failure to the restoration of operation. In computer systems, we also use "availability" to denote the system's operational efficiency, which refers to the probability of the computer system functioning normally at any given time. It can be expressed as:

$$
A = \frac{MTBF}{MTBF + MTTR}
$$

The reliability measurement of a computer typically relies on the aforementioned concepts.

## Reliability of series components

In a series system composed of $N$ components connected sequentially end-to-end, the entire system operates normally only when all components function properly. If the reliability of these components is $R_{1}, R_{2}, R_{3}, ..., R_{N}$, and their failure rates are $\lambda_{1}, \lambda_{2}, \lambda_{3}, ..., \lambda_{N}$, then:

The overall reliability of the system is:

$$
R = R_{1} \times R_{2} \times ... \times R_{N}
$$

The overall failure rate of the system is:

$$
\lambda = \lambda_{1} + \lambda_{2} + \lambda_{3} + ... + \lambda_{N}
$$

## Reliability of parallel components

In a parallel system composed of $N$ components connected in parallel, the entire system operates normally as long as at least one component functions properly. In a parallel system, only one component is essential, while the remaining $N-1$ components are redundant. The more redundant components there are, the higher the system reliability. Assuming the reliability of these components is $R_{1}, R_{2}, R_{3}, ..., R_{N}$:

The overall reliability of the system is calculated as:

$$
R = 1 - (1-R_{1})(1-R_{2})...(1-R_{N})
$$

Assuming the failure rate of all components in the system is $\lambda$, the overall failure rate of the system is:

$$
\mu = \frac{1}{\frac{1}{\lambda}\sum_{j=1}^{N}\frac{1}{j}}
$$

## N-modular redundancy system

An N-modular redundancy system consists of N (where $N = 2n + 1$) identical subsystems and one voting unit. When the system is operational, all subsystems simultaneously compute results, and the voting unit outputs the result that is in the majority, thus serving as the final outcome. This setup helps to mitigate failures caused by random factors, ensuring the reliability of the system. If at least $n+1$ components function properly, then the entire system operates normally.

When a module in the system fails, the remaining modules continue to provide service, ensuring the system's availability. The level of redundancy in an N-modular redundancy system is determined by the value of N, with a higher N value indicating greater redundancy and reliability.

Assuming the voter is entirely reliable and each subsystem has a reliability of $R_{0}$ , the reliability of an N-modular redundancy system is calculated as:

$$
R = \sum_{i=n+1}^{N}\binom{i}{N}R_{0}^{i}(1-R_{0})^{N-i}
$$

In the United States' lunar exploration satellites, N-modular redundancy systems are utilized to construct the computer systems onboard the satellite to mitigate failures in the space environment.


Outlines computer system reliability, including series, parallel components, and N-modular redundancy.

System Reliability Model


GraphQL is a query language for APIs proposed by Facebook. Many consider it as an alternative to REST, while others find GraphQL more complex than REST with no clear benefits. What unique capabilities does GraphQL have beyond the scope of REST? Is there an objective and rigorous criterion to help us make a judgment?

Nop Platform, through rigorous mathematical reasoning, has reinterpreted the positioning of GraphQL, resulting in new design ideas and technical implementation solutions. Under this interpretation, the NopGraphQL engine achieves comprehensive superiority over REST, strictly speaking, in the mathematical sense.

In simple terms, **GraphQL can be seen as an improvement of REST in a pull mode**, to some extent, it **reverses the flow of information**.

```text
query {
    NopAuthDept__findAll {
        name, status, children {name, status}
    }
}
```

Equivalent to `/r/NopAuthDept__findAll?@selection=name,status,children{name,status}`

Through **mathematical equivalence transformations (form transformations)**, we can clearly see that GraphQL is essentially supplementing a standardized `@selection` parameter to REST, allowing selective fetching of results.

Traditional REST is equivalent to pushing all information from the backend to the frontend, where the frontend cannot finely participate in the information production and transmission process. In the implementation of NopGraphQL, if the frontend does not request the `@selection` parameter, it automatically degrades to the traditional REST model, returning all non-lazy fields. Lazy fields need to be explicitly specified for them to be returned to the frontend.

In the architecture of Nop Platform, GraphQL is not just a transport protocol on par with REST; it is a **universal mechanism for information decomposition and composition**. It helps us organize the information structure of the system more effectively.

The positioning of NopGraphQL is as a general decomposition and dispatch mechanism for backend service functions. The same service function can be simultaneously published as a REST service, GraphQL service, gRPC service, Kafka message service, Batch processing service, etc. In simple terms, any scenario that involves receiving a Request Message and returning a Response Message can be directly integrated with the NopGraphQL engine as its implementation mechanism.

Using GraphQL has the following advantages compared to traditional REST:

## 1. Automatically trimming data loading scope based on requested data, achieving performance optimization

```text
@BizQuery
public PageBean<NopAuthUser> findPage(@Name("query") QueryBean query, FieldSelectionBean selection, IServiceContext context){
    PageBean<NopAuthUser> pageBean = new PageBean();
    if(selection != null && !selection.hasField("total")){
        long total = dao.countByQuery(query);
        pageBean.setTotal(total);
    }
    // ...
}
```

If the frontend does not require the total to be returned, the calculation of the total property can be skipped.

## 2. Automatic DTO adaptation by the engine, greatly enhancing the composability of data models

In traditional REST services, service functions directly return DTO objects, and all properties of DTO objects must be loaded in the service function. For example, if a virtual roles field is added to the NopAuthUser entity, it needs to be added to the DTO, and all places that return NopAuthUserDTO need to supplement the loading logic for the roles field. In NopGraphQL engine, the object returned by the service function is not directly serialized into JSON and returned to the frontend. Instead, it is processed further by the GraphQL engine using DataLoader to obtain the final returned data. This can significantly improve the composability of backend data models.

```java
@BizQuery
public List<NopAuthUser> findList(){
    // ...
}

@BizQuery
public NopAuthUser get(@Name("id") String id){
    // ...
}

@BizLoader
public List<String> roles(@ContextSource NopAuthUser user){
    // ...
}
```

In the example above, the findList and get functions only need to know how to load NopAuthUser objects, without needing to know how NopAuthUser is associated with NopAuthRole objects. Service functions can directly return entity objects without the need for manual translation into DTO objects. When we add a dynamic property roles to the NopAuthUser type through the `@BizLoader` mechanism, all places in the returned result that involve NopAuthUser automatically gain the roles property. The knowledge provided by DataLoader, through the action of the NopGraphQL engine, automatically combines with the functions we manually write, such as get/findList.

In NopGraphQL, we can also use an additional xmeta metamodel file to independently control the permissions, transformation, and validation logic of each field, simplifying and standardizing the implementation of service functions.

## 3. GraphQL's selection capability is a beneficial complement to the concept of aggregate roots in DDD

In Domain Driven Design (DDD), a critical and important design for information space planning is the concept of aggregate roots. Aggregate roots act as core nodes in the information space, allowing traversal in the information space by establishing direct connections with a few core nodes. Aggregates organize information in a form on the surface, reducing cognitive and usage costs, but it also has a negative impact on performance. GraphQL's selection capability is a complementary ability to the ability to aggregate (aggregation and selection as dual operations should be paired in design). It allows us to selectively extract slices of information we need from a vastly complex information structure, precisely meeting our business requirements.

## 4. GraphQL clearly distinguishes between query and mutation in terms of semantics, aligning more with the original intent of REST's Representational State Transfer design

Although REST specifies GET and POST methods, due to limitations at the implementation level (GET method does not support passing data through the HTTP body, URL length limitations, and security issues), we often cannot accurately differentiate the semantics of service functions through GET/POST. In the NopGraphQL framework, it is conventionally agreed that queries have no side effects and do not modify the database, while mutations have side effects and require consideration of transaction management, etc. Therefore, in the NopGraphQL framework, there is no need to manually add the `@Transactional` annotation for each service function; instead, a unified transaction environment is established for all mutation operations. Through optimizations at the implementation level, if a mutation does not actually access the database, the NopGraphQL framework does not actually obtain a database connection.

The NopGraphQL engine decomposes the execution of backend service functions into two phases: 1. Execute the service function, automatically establishing a transaction environment for mutations. 2. Process the result object returned by the service function, performing data transformation and pruning through DataLoader.

After the first phase is completed, the transaction is automatically closed, and some resource-consuming data loading tasks do not start executing. In the second phase, the transaction is closed, and the OrmSession is set to readonly. If entity data is inadvertently modified, an exception is automatically thrown. In this way, we can reduce the time the transaction is open and the time the database connection is occupied.


This article analyzes GraphQL's unique capabilities in API design, highlighting its advantages over REST, such as optimized data loading, enhanced data model composability, and improved semantic clarity in queries and mutations.

Why the Graphql Is Better than Restful in Math Conclusion?


In software engineering, while module dependencies ideally form a **tree structure**, real-world implementations often adopt **Directed Acyclic Graphs (DAGs)** to enable practical code reuse. This article explores three fundamental patterns of module organization and their implications.

## Ideal Scenario: Hierarchical Tree Structure

### Characteristics of Tree Architecture

```plantuml
@startuml
top to bottom direction

rectangle "Core" as A
rectangle B
rectangle C
rectangle D
rectangle E
rectangle F

A --> B
A --> C
B --> D
B --> E
C --> F
@enduml
```

**Key Features:**  

- Unidirectional dependencies (parent → child)  
- Clear hierarchical separation (e.g., UI → Business Logic → Data Layer)  
- No circular references  

**Common Implementations:**  

- MVC Architecture  
- Clean Architecture  
- Three-Layer Pattern (Presentation/Logic/Data)

**Advantages:**  
✅ Straightforward dependency management  
✅ Explicit separation of concerns  
✅ Simplified testing and maintenance  

**Challenges:**  
⚠️ Limited code reuse opportunities  
⚠️ Potential for artificial module fragmentation  
⚠️ Suboptimal for complex systems with cross-cutting concerns  

## Practical Reality: Directed Acyclic Graph (DAG)

### Modern Dependency Management

```plantuml
@startuml
top to bottom direction

rectangle A
rectangle B
rectangle C
rectangle D
rectangle E
rectangle F

A --> B
A --> C
B --> D
B --> E
C --> F
C --> E
@enduml
```

**Key Features:**  

- Shared modules between components (E shared by B/C)  
- Multiple dependency paths  
- Strictly acyclic  

**Real-World Applications:**  

- React/Vue Component Systems  
- Webpack Module Federation  
- Bazel Build System  
- Database Schema Design  

**Advantages:**  
✅ Natural code reuse through shared modules  
✅ Flexible architecture for complex systems  
✅ Maintains dependency integrity  

**Implementation Considerations:**  
🔧 Requires robust tooling (TypeScript path resolution, Webpack aliases)  
🔧 Needs dependency visualization tools  
🔧 Demands strict code review practices  

## Anti-Pattern: Circular Dependencies

### Dangerous Dependency Loops

```plantuml
@startuml
top to bottom direction

rectangle A
rectangle B
rectangle C
rectangle D
rectangle E
rectangle F

A --> B
A --> C
B --> D
B --> E
C --> F
C --> E
E --> A
@enduml
```

**Consequences:**  
❌ Runtime initialization errors (`Cannot access 'X' before initialization`)  
❌ Compilation failures (ESM/TypeScript circular reference errors)  
❌ Unmaintainable "spaghetti code" structure  

**Common Culprits:**  

- Bidirectional controller-service relationships  
- Shared state management traps  
- Improper dependency injection  

## Architectural Strategies

### 1. Dependency Hoisting

Elevate shared dependencies to higher-level modules to prevent duplication while maintaining acyclicity.

### 2. Dependency Injection

Implement IoC containers to manage cross-module dependencies:

```typescript
// Angular-style DI example
@Injectable({ providedIn: 'root' })
export class SharedService {
  // Reusable business logic
}
```

### 3. Module Federation

Modern solutions for microfrontend architectures:

```javascript
// Webpack Module Federation Configuration
new ModuleFederationPlugin({
  name: 'app1',
  exposes: {
    './Widget': './src/components/Widget',
  }
})
```

## Industry Case Studies

| System Type        | Dependency Pattern | Notable Implementations       |
|---------------------|--------------------|-------------------------------|
| Frontend Frameworks | DAG                | React Component Tree, Vue SFC |
| Build Systems       | DAG                | Webpack, Turborepo, Bazel     |
| Microservices       | Tree/DAG Hybrid    | AWS Lambda Layers, NestJS     |
| Database Schemas    | DAG                | Foreign Key Relationships     |

## Best Practices Checklist

1. **Static Analysis**  
   - Enable TypeScript's `--noImplicitCircularity`  
   - Use ESLint `import/no-cycle` rule  

2. **Dependency Visualization**  

   ```bash
   npx madge --image graph.svg src/index.ts
   ```

3. **Architectural Guardrails**  
   - Enforce layer access rules in `tsconfig.json`  
   - Implement module boundary checks in CI pipelines

4. **Refactoring Techniques**  
   - Apply Dependency Inversion Principle (DIP)  
   - Utilize facade patterns for cross-module communication  

> "Good architecture maximizes the number of decisions not made."  
> ― Robert C. Martin (*Clean Architecture*)

By understanding these fundamental patterns and implementing appropriate guardrails, teams can create maintainable systems that balance architectural purity with practical reuse requirements.


In software engineering, the reference relationship of software modules should ideally be a tree, but in practical applications, in order to reuse certain module structures, a directed acyclic graph is often formed.

NOTE & BLOG

SOFTWARE-THEORY

System Reliability Model

Why the Graphql Is Better than Restful in Math Conclusion?

How to Organize Modules in Software Architecture