Why Systems Overshoot
There is a critical element that sits between stocks and flows that most people overlook: Delays. A delay is the time gap between when an action is taken and when its effect is felt on a stock.
Think of a shower with old plumbing. You turn the handle toward "hot." Nothing happens for 10 seconds. You turn it more. Still cold. You crank it all the way. Suddenly, scalding water hits you. You jerk it back to cold. Ten seconds of scalding, then freezing. You oscillate wildly because the delay between your action (turning the handle) and the feedback (feeling the temperature) prevents you from calibrating correctly.
Engineering Examples of Delays:
- Auto-scaling: You configure an autoscaler to add nodes when CPU exceeds 80%. But new nodes take 3 minutes to provision, pull images, and pass health checks. During those 3 minutes, CPU stays high, so the autoscaler keeps adding more nodes. By the time the first batch is ready, you have triple the capacity you need. Then CPU drops, the autoscaler removes nodes, and you're back to being under-provisioned. This oscillation is a direct result of the delay.
- Hiring: Your team is overwhelmed. You open a req. It takes 3 months to hire someone and another 3 months for them to ramp up. During those 6 months, the existing team burns out further, and some leave — creating more reqs. The delay between "deciding to hire" and "having a productive team member" is the root cause of the staffing death spiral.
- Monitoring: You deploy a change. Your metrics pipeline has a 5-minute aggregation window. The problem doesn't show up in dashboards for 5 minutes. By then, 5 minutes of users have been affected.
Why Delays Matter for DevOps:
Most system instability is not caused by the wrong action — it is caused by the right action applied too aggressively because the operator did not account for the delay. This is why Kubernetes Horizontal Pod Autoscaler has stabilizationWindowSeconds — it is explicitly designed to prevent oscillation by introducing intentional waiting before scaling down. PID controllers in industrial automation solve the same problem with proportional, integral, and derivative terms that account for delay.
Key Point: When you see a system oscillating (scaling up and down, flapping alerts, teams alternating between crunch and idle), look for a delay in the feedback loop. The fix is almost never "react faster" — it is "react more gently and account for the lag." This is why experienced SREs prefer gradual rollouts and conservative autoscaling policies over aggressive reactive ones.