1d:I[766481,["/_next/static/chunks/1hgzza8c-_-qd.js","/_next/static/chunks/1iddjfi-ouqid.js","/_next/static/chunks/2k8dg1img1f42.js","/_next/static/chunks/3e-dwlb-xrzai.js","/_next/static/chunks/1jyqd-5arjdtp.js","/_next/static/chunks/1wnhwfib62ya0.js","/_next/static/chunks/35d8psgr1uffw.js","/_next/static/chunks/3c7aiklt30u5y.js","/_next/static/chunks/1jrmwmk7ussc2.js","/_next/static/chunks/2kxafhthqphdd.js","/_next/static/chunks/1sotxhtrjppqq.js","/_next/static/chunks/1y6_-d2wp4im3.js","/_next/static/chunks/38ylntebt5zwc.js","/_next/static/chunks/1gh3iy2jirae4.js","/_next/static/chunks/2bz54ylfi_8wq.js"],"ClientHomeListContentItem"] 1f:I[27201,["/_next/static/chunks/1hgzza8c-_-qd.js"],"IconMark"] 1e:T54fa,

In most business systems, analytics dashboards are an essential part of day-to-day operations. They help managers track revenue, monitor system activity, and understand how the organization is performing.

I once worked on a task to extend an existing dashboard by adding revenue data from features that had been introduced later.

At first, the task looked straightforward. But once I started digging into the implementation, several issues became apparent:

API latency was increasing.
Data was spread across many relational tables.
The amount of data had grown significantly.
The dashboard contained multiple types of information, including KPIs, charts, tables, and heatmaps.
Existing formulas were already running in production and were not good candidates for major changes.

Because delivery time and stability were important, rewriting the entire data computation flow was not a practical option.

Instead, the new logic had to be added on top of the existing formulas and grouped with the current results.

That created an important constraint:

I could not significantly change how the data was produced. Most of the optimization had to happen around or after the existing computation flow.

This article focuses on that kind of problem.

1. Don’t Recompute What You Already Know

One of the first optimizations to consider is caching the final result at the API layer.

A basic cache-aside flow looks like this:

Request
   ↓
Check cache
   ↓
Cache hit ─────────→ Return
   ↓
Cache miss
   ↓
Compute
   ↓
Store in cache
   ↓
Return

The main advantages are straightforward:

Easy to introduce incrementally.
Low implementation overhead.
Minimal changes to the existing architecture.
Only frequently requested data ends up being cached.

However, caching does not completely solve the latency problem.

On a cache miss:

Cache hit  → 50ms
Cache miss → 5s

The request still pays the full computation cost.

Another issue is cache stampede.

If the cache expires and 20 requests arrive at nearly the same time, the system may end up doing:

20 requests = 20 expensive computations

A useful technique here is request deduplication, often called single-flight.

Instead of:

R1 → compute
R2 → compute
R3 → compute
...

the system can allow one request to perform the computation while the others wait for the same result:

           ┌─ R1 computes
R2 ────────┤
R3 ────────┤ wait for the same result
...
R20 ───────┘

The outcome becomes:

20 requests = 1 computation + 19 waiters

Caching and single-flight complement each other well.

Caching avoids repeated work across requests over time, while single-flight avoids duplicate work when multiple requests miss the cache at the same time.

2. Pre-computation for Fixed and Dynamic Time Ranges

Caching still depends on the first request.

If some results are highly predictable, it may be better to compute them in advance.

For example, a dashboard may provide predefined ranges such as:

Last 24 hours
Last 7 days
Last month
Last 3 months
Last year

Instead of:

User request
↓
Compute
↓
Return

the system can run a background process:

Scheduler
↓
Compute
↓
Store result
↓
User request
↓
Read pre-computed result

This works especially well for expensive reports with fixed time ranges.

Dynamic ranges

The harder case is when users can freely select a range using two datetime pickers.

For example:

2026-01-17
→
2026-09-09

Pre-computing every possible combination is not realistic.

A better approach is to divide the timeline into reusable aggregated building blocks, such as daily, weekly, or monthly blocks.

For example:

partial January
+
February
+
March
+
April
+
May
+
June
+
July
+
August
+
partial September

Instead of recomputing the entire range, the system can:

compute the left partial range
+
reuse complete monthly blocks
+
compute the right partial range

This can significantly reduce repeated computation.

However, not every metric can be merged in the same way.

Metrics such as:

SUM(revenue)
SUM(order_count)

are naturally additive.

But metrics such as:

AVG
COUNT DISTINCT
median
p95
conversion rate

require more care.

For example, with an average, storing only the average value of each block is usually insufficient.

Instead, the block should preserve values such as:

sum
count

so the final result can be reconstructed as:

globalAverage =
totalSum / totalCount

This leads to an important question when designing reusable aggregates:

Which metrics are actually composable across smaller blocks?

3. Don’t Let the Slowest Workload Block the Entire Dashboard

A dashboard often contains several independent computations.

For example:

Revenue      1.5s
Orders       2.0s
Users        1.0s
Heatmap      5.0s

If they run sequentially:

1.5 + 2 + 1 + 5 ≈ 9.5s

If they are independent, they may be executed in parallel.

In TypeScript, for example:

const [
  revenue,
  orders,
  users,
  heatmap,
] = await Promise.all([
  getRevenue(),
  getOrders(),
  getUsers(),
  getHeatmap(),
]);

The total time may then move closer to the slowest workload: ≈ 5s

However, concurrency does not mean “run everything at once.”

Turning 100 sequential database queries into 100 concurrent queries can create a different problem:

connection pool exhaustion
CPU spikes
database overload

The goal is not maximum concurrency.

The goal is controlled parallelism for workloads that are truly independent.

There is another related issue.

Suppose the dashboard contains:

KPI       600ms
Revenue   1.2s
Product   2s
Heatmap   7s

If everything is returned through:

GET /dashboard

The user may have to wait nearly 7 seconds before seeing anything.

An alternative is to split the dashboard into logical API groups:

GET /dashboard/overview
GET /dashboard/revenue
GET /dashboard/products
GET /dashboard/heatmap

The UI can then render progressively:

0.6s → KPI
1.2s → Revenue
2.0s → Product
7.0s → Heatmap

This does not necessarily reduce the heatmap’s actual computation time.

But it can significantly improve perceived latency.

That distinction matters:

Performance optimization is not always about making every computation faster. Sometimes it is about preventing the slowest computation from blocking the entire user experience.

4. When the Bottleneck Is No Longer Backend Computation

Sometimes the backend is already fast enough, but the dashboard still feels slow.

For example:

Server compute: 300ms
Response transfer: 2.5s
Browser processing: 1s

In this case, shaving another 50ms off the database query will not make much difference.

The entire request lifecycle should be considered:

Database
↓
Backend computation
↓
Serialization
↓
Network
↓
Browser
↓
Rendering

Cache hierarchy

Caching can exist at several layers:

Client memory
    ↓
Browser / HTTP cache
    ↓
API cache
    ↓
Pre-computed result
    ↓
Source computation

The closer a request can be resolved to the client, the more expensive downstream work can be avoided.

Not every system needs every layer.

But cache design is often easier to reason about when viewed as a hierarchy rather than as a single Redis layer.

Client-side server-state caching

Libraries such as:

TanStack Query
SWR
Apollo Client

can help reuse server data in the browser.

For example:

Dashboard
→ Detail page
→ Back to Dashboard

Without client-side caching, the application may fetch everything again.

With server-state caching, it can reuse existing data and optionally revalidate it in the background.

This does not make the first backend request faster.

It mainly reduces unnecessary repeated requests.

Payload optimization

The API should also avoid sending more data than the UI actually needs.

If a chart only needs:

{
  "date": "2026-09",
  "revenue": 5000
}

there is little value in also returning large nested relations, metadata, audit logs, and unused fields.

Oversized responses increase:

serialization cost
network transfer time
memory usage
browser parsing cost

The same idea applies to data granularity.

If the chart can meaningfully display only a limited number of points, returning millions of raw events is usually unnecessary.

A better flow may be:

raw events
↓
hourly/daily buckets
↓
chart

For large tables, pagination and lazy loading are usually better than sending the full dataset in one response.

5. When the Workload Is Too Heavy for a Synchronous Request

Some operations are simply not a good fit for synchronous HTTP.

Consider an export job that takes 30 seconds:

Export two years of report data
→ 30 seconds

Instead of:

Client
↓
wait 30s
↓
download

the operation can be moved to a background job:

POST /exports
↓
202 Accepted
↓
return jobId

The worker can then:

Aggregate data
↓
Generate file
↓
Store file
↓
Notify user

The client can receive updates through:

Polling
WebSocket
SSE
System notification
Email

In this case, optimization does not necessarily mean:

30s → 3s

It may simply mean:

Don’t force the user to keep a synchronous HTTP request open for 30 seconds.

6. Measurement and Failure Handling

Performance optimization should not be based only on intuition.

Instead of saying:

This API feels slow.

it is better to measure:

p50
p95
p99
cache hit rate
response size
database time
aggregation time
serialization time

For example:

Before

p50: 1.8s
p95: 7.4s
p99: 11.2s
response size: 2.8 MB

After optimization:

After

p50: 250ms
p95: 1.8s
p99: 6.5s
cache hit rate: 82%
response size: 620 KB

This tells a more useful story.

The median request may now be much faster, while p99 is still relatively high.

That could indicate that cache misses or specific workloads remain expensive.

Measurement helps identify what actually improved and what still needs work.

Failure handling

The happy path is only part of the system.

Suppose Redis becomes unavailable.

A simple fallback may be:

Redis error
↓
compute from source
↓
return

That looks reasonable until 100 requests do the same thing at once:

100 requests
↓
100 expensive computations
↓
database overload

A cache failure can therefore cascade into a larger failure.

This is where mechanisms such as the following may become useful:

single-flight
rate limiting
stale cache
circuit breaker

Failure handling is not just about catching exceptions.

It is about controlling how failures propagate through the system.

The same principle applies to pre-computation.

Instead of:

delete old result
↓
compute new result
↓
computation fails
↓
no data

a safer approach is:

Current result: v42
↓
Compute v43
↓
Success?
├─ yes → switch to v43
└─ no  → keep serving v42

The old result should remain available until the new result has been successfully generated.

For background jobs, the lifecycle should also be explicit:

PENDING
↓
PROCESSING
↓
COMPLETED / FAILED

Retries should be designed together with idempotency so that the same logical job does not accidentally create duplicate files, duplicate notifications, or other repeated side effects.

7. When Should You Move to a Larger Architectural Change?

There are many stronger solutions for analytical workloads:

Materialized Views
PostgreSQL aggregate tables
TimescaleDB
ClickHouse
Elasticsearch
BigQuery
Data Warehouse

These technologies can be excellent choices.

But a powerful technology is not automatically the right solution for every task.

I find it useful to separate optimizations into two groups.

Tactical optimizations

cache
single-flight
pre-computation
parallel computation
API splitting
payload optimization
frontend caching
background jobs

Typical advantages:

reuse existing logic
lower implementation cost
lower migration risk
faster delivery

Architectural optimizations

Materialized Views
Aggregate tables
ClickHouse
TimescaleDB
Data Warehouse
BigQuery

These can provide better long-term scalability for analytical workloads, but they also introduce additional costs:

data migration
data pipelines
synchronization
infrastructure
monitoring
operational complexity

So the real question should not simply be:

Which technology is faster?

A better question is:

What level of architectural complexity is justified by the current bottleneck and system constraints?

Conclusion

When dealing with a slow dashboard, I usually think through the problem in roughly this order:

Are we recomputing the same result?
        ↓
Can we cache or pre-compute it?
        ↓
Can dynamic ranges be built from reusable aggregates?
        ↓
Are independent computations running sequentially?
        ↓
Is one slow workload blocking the entire UI?
        ↓
Are we transferring more data than the UI needs?
        ↓
Should this workload even be synchronous?
        ↓
Are we measuring the optimization?
        ↓
What happens when cache, workers, or pre-computation fail?

In my case, the main constraint was that I could not significantly change how the data was originally computed.

So instead of immediately rewriting the data layer, the more practical approach was to:

Reuse before recomputing
Pre-compute predictable workloads
Compose dynamic ranges when possible
Parallelize independent work
Avoid blocking the entire UI on the slowest workload
Reduce unnecessary data transfer
Move long-running work to background jobs
Measure before and after optimization
Design for failure paths, not only happy paths

A good optimization is not necessarily the most sophisticated one.

It is the one that addresses the actual bottleneck while keeping implementation cost and architectural complexity appropriate for the system.

9:["$","div",null,{"className":"min-h-screen flex flex-col w-full p-4 items-center gap-4","children":[["$","h1",null,{"className":"text-2xl font-semibold text-slate-900 dark:text-slate-100 uppercase","children":"content by tag: latency-optimate"}],["$","div",null,{"className":"flex w-full max-w-[1200px] flex-1 flex-col gap-5","children":[["$","div",null,{"className":"flex h-full w-full flex-1 flex-col items-center","children":["$","div",null,{"className":"mx-auto flex w-full flex-col gap-2.5 sm:gap-3","children":[["$","$L1d","client-content-item-e246e8ac-229a-42f5-8a5e-0acba47c1e51",{"content":{"_id":"e246e8ac-229a-42f5-8a5e-0acba47c1e51","created_at":"2026-09-23T06:53:22.074Z","updated_at":"2026-09-23T10:55:06.407Z","index":50,"title":"Optimizing Dashboard Latency When You Can’t Change How the Data Is Computed","slug":"optimizing-dashboard-latency-when-you-can’t-change-how-the-data-is-computed","body":"$1e","short_description":"In most business systems, analytics dashboards are an essential part of day-to-day operations. They help managers track revenue, monitor system activity, and understand how the...","time_read":13,"image":"/storage/take/content/261e5483-2160-4118-9c12-c88a242a980f.webp","status":"PUBLISHED","watches":["5933151b-256d-4fd0-a077-f697c7538590"],"count_view":2,"member_up_vote":[],"member_down_vote":[],"tags":["System Design","Latency Optimate"],"slugTags":["system-design","latency-optimate"],"bookmark_by":[],"images":[],"locale":"en","other_locale_content_id":"b82aa4c7-9b9c-48c8-9f17-6076c5f49ac9","category":{"_id":"c6a68f30-4dcf-4854-9acf-17fa388e305e","created_at":"2026-05-01T07:33:12.927Z","updated_at":"2026-08-19T05:32:53.728Z","index":5,"title":"Programming & Engineering","slug":"programming-engineering","description":"Programming & Tech - Technical Knowledge Sharing","locale":"en"},"series":null},"language":"en","eager":true}]]}]}],false]}]]}] c:null 13:[["$","title","0",{"children":"Posts Tagged \"latency-optimate\" - Nguyễn Hoàng Lâm's Blog"}],["$","meta","1",{"name":"description","content":"Discover posts related to \"latency-optimate\" on Nguyễn Hoàng Lâm's blog. Explore knowledge and experiences in programming, technology, and life shared through posts tagged with this label."}],["$","meta","2",{"name":"application-name","content":"Blog Cá Nhân"}],["$","meta","3",{"name":"author","content":"Nguyễn Hoàng Lâm"}],["$","meta","4",{"name":"generator","content":"nextjs"}],["$","meta","5",{"name":"keywords","content":"Nguyễn Hoàng Lâm,latency-optimate,tech blog,programming,knowledge sharing,personal experiences,tech trends"}],["$","meta","6",{"name":"referrer","content":"origin"}],["$","meta","7",{"name":"creator","content":"Nguyễn Hoàng Lâm"}],["$","meta","8",{"name":"publisher","content":"Nguyễn Hoàng Lâm"}],["$","meta","9",{"name":"robots","content":"index, follow"}],["$","meta","10",{"name":"abstract","content":"Discover posts related to \"latency-optimate\" on Nguyễn Hoàng Lâm's blog. Explore knowledge and experiences in programming, technology, and life shared through posts tagged with this label."}],["$","meta","11",{"name":"category","content":"Technology, Programming, Life, Personal Experiences"}],["$","meta","12",{"name":"classification","content":"Blog"}],["$","link","13",{"rel":"canonical","href":"https://beespark.net/en/by-tag/latency-optimate"}],["$","meta","14",{"name":"format-detection","content":"telephone=no"}],["$","meta","15",{"property":"og:title","content":"Posts Tagged \"latency-optimate\" - Nguyễn Hoàng Lâm's Blog"}],["$","meta","16",{"property":"og:description","content":"Discover posts related to \"latency-optimate\" on Nguyễn Hoàng Lâm's blog. Explore knowledge and experiences in programming, technology, and life shared through posts tagged with this label."}],["$","meta","17",{"property":"og:url","content":"https://beespark.net/en/by-tag/latency-optimate"}],["$","meta","18",{"property":"og:site_name","content":"Nguyen Hoang Lam Blog"}],["$","meta","19",{"property":"og:locale","content":"en_US"}],["$","meta","20",{"property":"og:image","content":"https://beespark.net/logo/logo.png"}],["$","meta","21",{"property":"og:image:alt","content":"Discover posts related to \"latency-optimate\" on Nguyễn Hoàng Lâm's blog. Explore knowledge and experiences in programming, technology, and life shared through posts tagged with this label."}],["$","meta","22",{"property":"og:type","content":"website"}],["$","meta","23",{"name":"twitter:card","content":"summary_large_image"}],["$","meta","24",{"name":"twitter:title","content":"Posts Tagged \"latency-optimate\" - Nguyễn Hoàng Lâm's Blog"}],["$","meta","25",{"name":"twitter:description","content":"Discover posts related to \"latency-optimate\" on Nguyễn Hoàng Lâm's blog. Explore knowledge and experiences in programming, technology, and life shared through posts tagged with this label."}],["$","meta","26",{"name":"twitter:image","content":"https://beespark.net/logo/logo.png"}],["$","link","27",{"rel":"icon","href":"/favicon.ico?favicon.0qvlwmw4zqvg4.ico","sizes":"256x256","type":"image/x-icon"}],["$","link","28",{"rel":"icon","href":"https://beespark.net/favicon.ico"}],["$","$L1f","29",{}]]

content by tag: latency-optimate

Optimizing dashboard latency when you can’t change how the data is computed