Sales Performance Dashboard
A sales performance dashboard recomputed everything on demand against a legacy system I was not allowed to touch, query directly, or ask for a push feed. Here is what I could change, and what it cost.
Senior Backend Developer, sole owner
2024, Berijalan Technocenter
Spring Boot, Kafka, CDC, Alibaba Cloud
~3 min → < 1 s, CPU spikes gone
What was actually wrong
Every time a sales manager opened the performance dashboard, the service recomputed aggregates on demand by calling into a slow legacy application. Page load sat at roughly three minutes. Worse, the load arrived in bursts — everyone opens the dashboard at the end of the reporting period — so the underlying database spiked its CPU exactly when the rest of the business needed it most.
The obvious fix, computing less, was not available: the numbers were the product. The second obvious fix, computing them ahead of time, required getting the data out of a system that offered no supported way to do that.
Three things I could not change
No database access
Direct reads against the source database were forbidden by policy. Not slow — forbidden.
Unmodifiable app
The legacy application could not be changed, so no hooks, no outbox table, no new endpoints.
No push mechanism
Nothing in the source would notify us when data changed. Every option had to discover change itself.
What I rejected, and why
Poll the existing API on a schedule
Simplest to build and needs no new infrastructure — but it re-creates the load problem on a timer instead of removing it, and the polling interval becomes the freshness ceiling.
Read the source database directly
Technically the cleanest read path and the one a greenfield design would pick. Ruled out by access policy before any engineering argument could apply.
Change Data Capture into Kafka
Observes change at the log level without touching the application, and the company already ran Kafka — so the marginal infrastructure cost was close to zero. Buys pre-aggregation at the price of eventual consistency.
The read path never touches the legacy system again. The write path absorbs the cost, asynchronously.
Stress-tested under burst load: worst-case consumer lag ~10 s.
The numbers are now slightly stale, and users can see exactly how stale.
Pre-aggregation buys speed with freshness. Rather than hide that, the dashboard surfaces a last-sync timestamp, so a manager reading a number knows the moment it was true. Hiding eventual consistency is how you get people quietly mistrusting a system; showing it is how you get them to plan around it.
That decision also made the failure mode legible in production. A stale timestamp is a visible symptom of consumer lag — the dashboard became its own monitor.
One integration platform configured per client at runtime, instead of a fork per customer in code — and no engineering work required from the client to onboard.