Design Overview not loading

[alexevansvu]

What product would you like to leave feedback for?

Console

What Console version are you using?

Mia-Platform v14.5.3

Description

We're having a problem where the design overview page is timing out for companies with many services in their projects. I did some analysis on the logs emitted by the Mia Console services involved with loading this page, as well as the HTTP requests being passed around and what I found was that for each project, the page was hitting the CRUD service twice and pulling the full configuration each time.

The average time per project was approximately 400ms for first request , and approximately 150ms for the second. Multiplied by 50+ projects this approaches 30 seconds on the request and leads to the api-gateway to time out. We're looking into re-indexing to try to get the CRUD requests to execute faster, but we think we're fighting a losing battle doing so. We're wondering if you have any advice, or if there was any performance optimization you can perform on your end.

Included below is an AI generated summary of the investigation I did leading me to the conclusions I've drawn.

---

Investigation: Microservice Page Load Failure

Date: May 2026

Reported symptom: Frontend page appears stuck and the microservice list never loads.

---

Summary

The page fails to load microservice data due to an apparent N+1 query pattern in the service responsible for generating tenant overview data.

When processing a tenant containing 50+ projects, the service issues approximately 100 sequential configuration queries (two per project). Each query returns a large configuration payload (~250–290 KB). As a result:

• The initial request to retrieve distinct microservice values takes approximately 27 seconds
• The subsequent microservice search request exceeds the frontend/API timeout threshold and fails before a response is returned

The underlying configuration service remains responsive throughout the process. The observed latency appears to be caused by the serial execution pattern in the tenant overview workflow rather than by slow individual database or CRUD operations.

---

Key Evidence

1. Initial distinct-values request

A request to retrieve distinct microservice values completed successfully but required approximately 27 seconds to finish.

GET .../microservice/distinct-values

responseTime: 27354ms
statusCode: 200
responseSize: 521 bytes

2. Subsequent microservice search timeout

Immediately after the distinct-values request completed, a follow-up search request was issued.

POST .../microservice/search

responseTime: 29998ms
statusCode: 0
responseSize: 0

The client connection was closed before processing completed. The backend finished the request several seconds later, but the response could no longer be delivered to the browser. This is the direct cause of the blank page experienced by users.

---

Request Trace

Phase 1: Project discovery (~0.8s) — Normal

The workflow begins by:

1. Performing authorization checks
2. Retrieving the project count
3. Loading the project list
4. Loading tenant metadata

For the affected tenant, approximately 53 projects were identified. This phase completed in under one second and does not appear to contribute materially to the issue.

Phase 2: Per-project configuration fetches (~26s) — Primary Bottleneck

For each project, the service performs two sequential configuration lookups:

1. Retrieve the most recent configuration record
2. Retrieve related configuration variants using data returned from the first query

Observed characteristics:

Metric	Value
Projects processed	53
Queries per project	2
Total configuration queries	~106
Average payload size	~265 KB
Average first query latency	~400 ms
Average second query latency	~150 ms

Estimated total processing time:

53 projects × (~550ms per project) ≈ 29 seconds

The queries are executed serially, meaning each project must complete both requests before processing continues to the next project.

Additionally, each query appears to retrieve large configuration documents even though only a small subset of metadata fields may be required for the subsequent processing steps.

---

Apparent Potential Root Cause

The tenant overview workflow processes configuration retrieval using a serial per-project loop rather than batching or parallelizing requests.

This results in runtime increasing linearly with project count. As tenant size grows, response times eventually exceed frontend or gateway timeout thresholds.

A later step in the same workflow demonstrates a more efficient pattern: a single batched query is used to retrieve microservice-related data across many projects simultaneously, returning results in only a few tens of milliseconds.

Applying a similar batching strategy to the configuration retrieval phase would likely eliminate the majority of the observed latency.

The evidence suggests that the bottleneck is not the underlying data service itself, but rather the orchestration pattern used by the tenant overview component.

---

Conclusion

The microservice page load failure is caused by an N+1 query pattern in the tenant overview workflow. For tenants with a large number of projects, the service performs more than 100 configuration queries sequentially, resulting in request times that exceed frontend timeout limits.

The underlying data service remains responsive, indicating that the primary issue is request orchestration rather than storage-layer performance. Batching or parallelizing configuration retrieval should significantly reduce page load times and eliminate the observed timeout behavior.

[KarissaBrummell]

For additional context, here is a screenshot of this happening:

[nicola88]

Hi @alexevansvu @KarissaBrummell thanks for reporting the issue, we will investigate and get back to you when we have updates.

[ThisIsDemetrio]

Hi @alexevansvu . We're sorry to hear you're having issues with the Design Overview, but thanks for sharing these information with us, as well with the AI analysis which gives us interesting insights.

The Design Overview section, and its related BFF, has always shown poor performances in companies that includes a lot of projects (especially those with many collections, microservices and endpoints). We are working on a patch to improve the performances of the section, which I hope we can share with you soon.

As a mitigation, or to better understand where the bottleneck are, you might want to check the logs of the CRUD Service to see which requests requires a lot of time. The two requests performed by the Design Overview to its BFF executes requests to the CRUD Service on the collection configurations (to retrieve projects details) and control-panel-data (to cache some of these information).

From there you can probably identify some bottlenecks to better understand which indexes can be changed and/or some projects can be simplified. Remember as well that the Design Overview shows information about project configurations at their default branch, meaning that if a project includes its config to a different branch, the Design Overview might not show them.

Again, thanks for opening this discussion, and I hope we can get back to you soon with some updates.

Cheers,
|D|

[albertotessarotto]

Good morning, a new Mia-Platform Console patch release is now available: v14.5.5.
Here are the release notes.

We suggest updating the Helm chart version to v15.0.11-hotfix.4. Please let us know if you notice any performance improvements in the Design Overview section.
Cheers,

Alberto