The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
A system can be fast most of the time and still create a bad experience when it matters most.
Imagine two services.
One usually responds in 5 milliseconds, but occasionally takes 500.
The other usually responds in 7 milliseconds and rarely goes above 12.
The first looks faster if you only look at the average.
But under real traffic, those occasional delays can become the difference between a smooth experience and customers waiting, requests timing out, or downstream systems backing up.
This changed how I think about performance.
I no longer ask only:
“How fast is the system?”
I also ask:
How consistent is it under load?
What happens to the slowest 1% of requests?
Does performance degrade when traffic increases?
Can one slow dependency create delays across the system?
This is why p95 and p99 latency matter.
Good performance engineering is not just about making the average request faster. It is about making the system predictable when conditions are less than ideal.
Average performance can hide a lot.
If 99% of requests are fast but the remaining 1% are extremely slow, that can still represent thousands of poor experiences at scale.
That is why I increasingly care about the shape of performance, not just the headline number.
Predictability is...
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
Building smooth room to room transitions and dynamic color updates virtual touring website with Next.js, TypeScript, and powered entirely by Replit infrastructure and PostgreSQL. What do you guys think of the transition flow?
room to room transitions are tricky, how are you handling the loading between them
Onboarding feels fast when every step hands off to the next.
Slide the screen, fill the progress, roll the number. No spinners, no dead frames.
Capacity burn-up UI.
Track team workload, spot capacity risks early, and rebalance work before teams get overloaded.
Light & Dark modes.
2 voted
33%
4 voted
67%
6 votes
Closed
This is the kind of dashboard that actually gets used — the burn-up chart makes overload visible at a glance instead of hiding it in a table somewhere. I like that the point is spotting the risk early, not just reporting it after the fact. Both modes read well, though the dark one makes the chart pop a bit more for me.