Unisala's current architecture needs to be evaluated to determine its capacity to handle concurrent users. This is critical for ensuring system reliability, identifying bottlenecks, and making informed decisions about future scaling and migration to EKS

Without a thorough evaluation of Unisala’s architecture, we risk system failures, degraded user experiences, and an inability to scale effectively, putting our growth and reliability at stake. This evaluation is the first step in ensuring we can handle increasing demands and future-proof our platform

.

Why It Matters:

• Demonstrates professional engineering practices.
• Identifies system bottlenecks and performance limits.
• Guides architectural decisions for scaling and future planning.
• Provides baseline metrics for comparing performance post-EKS migration.

Objective:

1. Determine the maximum number of concurrent users Unisala can support in its current architecture.
2. Identified key bottlenecks (e.g., database connection limits, memory leaks under sustained load).

What Are We Measuring?

To evaluate the system’s capacity and identify breaking points, we need to measure the following key metrics:

1. Response Time:

The time taken by the system to process a request and return a response.

1. Why It Matters: Indicates how well the system performs under load. High response times signal performance degradation.
2. How to Measure: Track average and peak response times for critical user flows (e.g., login, data retrieval).

2. Error Rate:

The percentage of failed requests (e.g., HTTP 5xx errors, timeouts).

1. Why It Matters: High error rates indicate system failures or bottlenecks.
2. How to Measure: Monitor the ratio of failed requests to total requests under increasing load.

3. CPU Utilization

The percentage of CPU resources being used by the system.

1. Why It Matters: High CPU usage (e.g., 90-100%) indicates the system is nearing its processing capacity.
2. How to Measure: Track CPU usage across all application components (e.g., Node.js app, microservices).

4. Memory Usage

The amount of RAM being used by the system.

1. Why It Matters: High memory usage (e.g., 90-100%) can lead to crashes or slowdowns due to memory exhaustion.
2. How to Measure: Monitor memory consumption for all running processes.

5. Database Performance

Metrics related to database operations, such as query latency, connection pool usage, and deadlocks.

1. Why It Matters: Database bottlenecks (e.g., slow queries, maxed-out connections) can cripple the entire system.
2. How to Measure:

6. Query latency:

Time taken to execute database queries.

1. Connection pool usage: Percentage of active database connections.
2. Deadlocks: Number of queries stuck due to resource contention.

7. Network Throughput

The amount of data being transferred over the network (e.g., incoming/outgoing traffic).

1. Why It Matters: High network usage can lead to packet loss, delays, or saturation.
2. How to Measure: Track bandwidth usage (e.g., Mbps) and latency.

8. File Descriptor Usage

The number of open file descriptors (e.g., sockets, files) being used by the system.

1. Why It Matters: Running out of file descriptors can prevent new connections or file operations.
2. How to Measure: Monitor the number of open file descriptors and compare it to the system limit.

8. Request Queue Length

The number of requests waiting to be processed by the system.

1. Why It Matters: A growing queue indicates the system is unable to keep up with incoming requests.
2. How to Measure: Track the number of requests in the queue under increasing load.

What Are the Crucial Tests to Evaluate the System?

To measure the above metrics and identify breaking points, we need to run the following critical tests:

a. Baseline Load Test

Simulate normal user behavior to establish performance benchmarks.

What to Measure:

1. Response time under normal load.
2. Error rates.
3. Resource utilization (CPU, memory, network).

b. Stress Test

What It Is: Gradually increase the number of concurrent users until the system breaks.

What to Measure:

Breaking points (e.g., CPU exhaustion, memory exhaustion, database connection limits).

1. Maximum concurrent users before failure.
2. Error rates and response times at peak load.

c. Endurance Test

Apply sustained load over an extended period to identify long-term issues (e.g., memory leaks, database degradation).

What to Measure:

1. Memory usage over time.
2. Database performance under sustained load.
3. System stability and error rates.

d. Spike Test

Simulate sudden traffic spikes to see how the system handles abrupt increases in load.

What to Measure:

1. Response time and error rates during the spike.
2. Recovery time after the spike.

e. Failure Test

Intentionally introduce failures (e.g., kill a process, disconnect the database) to test system resilience.

What to Measure:

1. System recovery time.
2. Impact on response time and error rates.

Summary of Crucial Metrics and Tests

Evaluating Unisala's current architecture to determine its capacity for handling concurrent users is a foundational step in ensuring system reliability, scalability, and performance.

By systematically measuring critical metrics—such as response time, error rate etc. we can pinpoint bottlenecks, uncover breaking points, and establish baseline performance benchmarks.

The planned test will simulate real-world scenarios, revealing how the system behaves under normal, peak, and extreme conditions. These insights will not only highlight immediate limitations but also guide strategic decisions for scaling, optimizing, and migrating to EKS.

This evaluation is the first phase in a comprehensive effort to future-proof Unisala's architecture. By identifying and addressing performance constraints now, we can ensure the system is robust, resilient, and ready to support growing user demands.

In the next phase, we will execute these tests, analyze the results, and define actionable steps for architectural improvements and migration planning.

#unisala #architecture #systemDesign #review