When CPU looks fine but requests still stall
System Design
Tail latency and the waits a CPU profile misses
Where time goes when utilisation looks fine
Blog
Questions I keep coming back to
A growing collection of notes on performance, product, and the systems questions I keep circling.
Why “100 requests per minute” is not a rate-limiting strategy
System Design
Token buckets, fairness and the cost of saying no
Rate limits start with resource, identity and cost.
Why more options can make a simple task feel harder
Design
Defaults and disclosure make choices easier
Why adding servers does not automatically survive a traffic spike
System Design
What breaks first when traffic is not a smooth line
When product memory becomes surveillance
Product
What to remember, and when to forget
All posts
- Why making it bigger does not create visual hierarchyDesignhierarchytypographylayout
- Why disabling the button did not stop the duplicate requestSystem Designconcurrencyidempotencydatabases
- Why adding more whitespace does not fix an unclear interfaceDesignspacinggroupinglayout
- What 10,000 rows actually means for a React interfaceSystem Designreactvirtualisationpagination
- Why adding servers does not automatically survive a traffic spikeSystem Designqueuesbackpressureretries
- Why the empty state should come before the happy pathProductempty stateserror handlingux writing
- Why 10,000 database connections is not a database settingSystem Designconnection poolingpostgresdynamodb
- Why shrinking the desktop does not make a design responsiveDesignresponsivebreakpointslayout
- Why “100 requests per minute” is not a rate-limiting strategySystem Designrate limitingfairnessadmission control
- Why a component library can make product delivery slowerDesigndesign systemscomponentsconsistency
- Why buffering every log can make an incident worseSystem Designloggingobservabilitybackpressure