SaaS / AnalyticsPlatformă de Business Intelligence (Anonimă)

Dashboard de raportare care se strica la scară: problema de arhitectură a datelor din spatele unei interfețe lente

Un dashboard de raportare funcționa bine pentru conturi mici, dar se degrada serios cu date reale de producție. Echipa a presupus că este o problemă de frontend. Nu era — sau nu în totalitate. Interfața lentă era un simptom al unui strat de date neoptimizat dedesubt: interogări care fetchau mai mult decât era necesar, nicio agregare pentru vederile comune și un API care făcea mai multe roundtrip-uri acolo unde unul era suficient. Am adresat mai întâi stratul de date, apoi randarea. Ambele contau.

timp de interogare pe vederi comune
redus semnificativ după pre-agregare — scanările complete ale tabelelor eliminate pentru rapoartele cel mai des utilizate
multiple apeluri API → unul
pattern de cerere consolidat pentru încărcarea principală a raportului
paginare eliminată
utilizatorii pot derula prin seturi complete de date — workaround-ul cu spreadsheet a fost abandonat
stratul de date primul
optimizarea frontend singură ar fi recuperat poate 30% din câștig — problema reală era upstream

Provocarea

Dashboard-ul servea conturi cu zeci de mii de înregistrări. Încărcarea unui raport declanșa mai multe apeluri API secvențiale, fiecare returnând răspunsuri cu setul complet de date care erau apoi filtrate pe client. Nu exista pre-agregare pentru vederile de sumar pe care utilizatorii le deschideau cel mai des — acestea erau calculate din nou la fiecare cerere. Frontend-ul încerca apoi să randeze totul simultan. Echipa adăugase paginare ca workaround, dar interogările de bază rulau totuși pe întregul set de date indiferent. Utilizatorii power — cei cu cele mai mari conturi și cea mai mare influență asupra reînnoirilor — începuseră să exporte în spreadsheet-uri.

Soluția

Am început cu stratul de date. Am profilat cele mai utilizate interogări de rapoarte și am identificat unde aveau loc scanări inutile ale tabelelor complete. Am introdus tabele de sumar pre-agregate pentru cele mai comune cinci vederi, am actualizat API-ul să le servească direct în loc să calculeze din mers și am consolidat secvența de apeluri multiple într-o singură cerere cu un răspuns structurat. Odată ce stratul de date returna răspunsuri mai rapide și mai compacte, am adresat randarea: virtual scrolling pentru tabelele mari, inițializare amânată a graficelor pentru secțiunile de sub fold. Modificările au fost incrementale — fiecare pas era independent deployabil și măsurabil.

Am petrecut două sprinturi încercând să rezolvăm pe frontend și am văzut îmbunătățiri marginale. Când stratul de date a fost rezolvat, diferența a fost imediată. Ar fi trebuit să profilăm interogările primele.

Tech LeadPlatformă de Business Intelligence
arhitectură datedashboardperformanțăAPISaaS

Vrei rezultate similare?

Hai să discutăm despre contextul tău specific.

Contactează-ne