The site that you are currently viewing is a static version of the Software Factory documentation delivered with the

version v7.2.
For up-to-date documentation, see the latest version.

Size the Architecture

Optimize IT resource allocation by sizing your architecture to match actual needs, using scalability, stateless design, and frugal patterns.

7 minute read

Objectives

Optimize IT resource allocation

Precisely adapt the computing power and resources provided to the real needs of the application, avoiding any overprovisioning. This approach aims to limit unnecessary energy consumption and reduces the use of superfluous computer equipment, while ensuring efficient and flexible capacity management.

Strengthen operational efficiency and resilience

Dynamically adjusting resources reduces costs, optimizes performance and ensures system robustness in the face of changing uses, while limiting the environmental impact associated with overconsumption of resources.

Implementation

1. Precise quantification of the need

The “dimensions” of each functionality must be defined precisely and as a whole. It could be a compression rate for the images of the graphical interface, the maximum response time for an HTTP request, the number of items displayed in a list, etc. The more the dimensions and requirements associated with each feature align with the business case, the less resources are wasted. This level of requirement can vary depending on the need and the business case being addressed. But the general logic must be reversed compared to current practices. If a quantification is not specified, the minimum level of quality or quantity is proposed. Source

Example: By setting 480p (YouTube - 1.1 Mbps) instead of 1080p (5 Mbps) as default, bandwidth usage is reduced by 80% for most users. Source

2. Scalable solutions

A software solution generally has a load that varies over time. It must therefore be scalable to adjust hardware resources according to the actual load, in order to avoid over-provisioning resources while still being able to handle load peaks.

Definition of scalability

Scalability is the measure of a system’s ability to decrease or increase in performance and cost, in response to changes in processing demands. So, a scalable solution is expected to remain stable and maintain its performance after a steep workload increase or decrease, whether expected or spontaneous.

There are two types of scalabilities: vertical and horizontal.

Vertical scalability (Scale Up/Scale Down)

It is about increasing or decreasing a server’s capacity (CPU, RAM, disk …)

Example : You are using a virtual machine (VM) in a cloud service Azure. If your application requires more power, you can switch from a “B2ts_v2” instance to a larger instance like “DC4as_v6”, which offers more CPU and memory resources.

Vertical scaling
Source

Horizontal scalability (Scale Out/Scale In)

It’s about adding or removing servers/nodes

Example: During peak demand, a microservices-based application can scale horizontally by automatically adding service replicas using Kubernetes, which helps to distribute workload and maintain optimal performance. Once traffic returns to normal, Kubernetes reduces the number of replicas, optimizing costs and resources.

Horizontal scaling
Source

Choice of architecture

The architecture of the software solution must be tailored to its actual load and should allow real-time adjustment to it. Therefore, the choice of architecture must consider the system’s load. Let’s take a closer look at the different types of architecture:

An optimized monolithic architecture is suitable for a low-load solution. A low load corresponds to an activity level where a single optimized monolithic application can meet demand with acceptable performance, reliability and costs without requiring horizontal scalability or organizational decoupling. The analysis of the load is therefore carried out on both technical and organizational and economic criteria.
In other cases, the use of a decoupled architecture (modular services or microservices) is recommended. But this choice must be made only if the load justifies it.
This type of architecture requires attention to the notion of coupling in order not to induce an excessive additional resource consumption due to communication between components.
To learn more about this topic: Loose vs Tight Coupling: Tame Your Dependencies | by Manoj Nanduri | Medium

Dynamic autoscaling

The dynamic scalability of an application should be based on real-time analysis of metrics such as CPU or RAM usage, rather than on preventive adjustments aimed at over-provisioning resources.

3. Stateless application

A stateless application is an application that does not retain any information or state between different interactions with the user or requests. Each request is processed independently, without relying on previous actions or persistent data.
This type of application promotes horizontal scalability because its operating principle allows adding or removing a server without disrupting user sessions. This also allows to be more resilient in case of a failure of one of the servers.

How to make an application Stateless?
The principle of a Stateless application is not to store the state of a session on the server side. It is therefore necessary to externalize the state, for example through JWT (JSON Web Token) transmitted by the client or through a shared cache (Redis, Memcached). If storing progress during long processing or shared data is necessary, it should not be done on a local disk but via a database.

4. Serverless application (specific cloud deployment)

A serverless application is an architecture where the server infrastructure is abstracted and managed by a cloud provider. Functions run in response to events, and resources are allocated dynamically based on demand, without the need for manual server management.
Since the functions are started on event, they do not go into idle mode when they are not in use. Therefore, consumption related to under-utilization is reduced. However, one must take into account the “cold starts” of a function that has not been run for a long time and whose startup can consume more resources. It is a point of vigilance during developments.
This type of application allows for the optimization of resources used by dynamically adapting to the load without the need for over-provisioning.

To learn more about this topic: (PDF) SERVERLESS ARCHITECTURES: A COMPARATIVE STUDY ON ENVIRONMENTAL IMPACT AND SUSTAINABILITY IN GREEN COMPUTING

5. Sustainable and frugal solutions

Independent corrective updates

A software solution that is sustainable over time must allow for corrective updates, such as communication protocols, independently of functional updates. Thus, users will have the option to install functional updates while being assured that the security of the application is maintained through corrective updates. For this, the interfaces must be decoupled from the functional.

Use of standard protocols and format

The use of standard protocols and formats such as (HTTP, REST, gRPC, JSON, XML…) allows interoperability between different technologies. Indeed, software using such protocols can more easily integrate into a broader ecosystem (test, monitoring etc …), exchange data with other systems, and evolve with new technologies that emerge.

Their uses have other advantages:

Indeed, standardized formats are often designed to be extensible and flexible, allowing the software to adapt to new needs without requiring complete rewrites.
They benefit from long-term support from their large community, unlike proprietary protocols.

Bandwidth throttling

Bandwidth throttling is a method that regulates the frequency or volume of requests processed by a system, service or API. This prevents an instance from using network resources excessively, and thus limits resource overprovisioning for each instance.
By delimiting the network resources of an instance, this allows in a context of mutualization of resources to ensure a fair distribution of network resources for all applications.
To learn more about this topic: Bandwidth Throttling Rules for auto-scaling groups based on open standards - UMA Technology

Example :

Javascript

const rateLimit = require('express-rate-limit');

// Configure per-client rate limiting
const apiLimiter = rateLimit({ windowMs: 60 * 1000, // 1 minute window
max: 100, // 100 requests per window per client
message: { 
    error: 'Too many requests. Limit: 100 requests/minute',
    retryAfter: '60 seconds'
},
standardHeaders: true, // Return rate limit info in headers
legacyHeaders: false,

// Key by client IP or API key
keyGenerator: (req) => req.headers['x-api-key'] || req.ip
});

// Apply to API routes
app.use('/api/', apiLimiter);

// Tiered limits for different client types
const premiumLimiter = rateLimit({
  windowMs: 60 * 1000,
  max: 1000  // Premium clients: 10× limit
});

app.use('/api/', (req, res, next) => {
  if (req.user?.tier === 'premium') {
    return premiumLimiter(req, res, next);
  }
  return apiLimiter(req, res, next);
});