Aglet

How to learn from burst traffic and capacity boundaries

Burst learning preserves the load shape that exposed a shared limit and the recovery behavior that determined whether users were harmed. Record route mix, concurrency, resource boundary, overload contract, and post-burst checks so capacity discussions begin with observed evidence instead of broad assumptions.

Keep the lesson for the next incident

  1. Document the representative burst

    Keep arrival pattern, concurrency, duration, route mix, request sizes, environment, and critical actions together. Describe the first boundary that changed and the measurements supporting it. Separate expected traffic from synthetic stress so future readers understand what the case represents.

  2. Preserve the overload and drain contract

    Write how rejected, delayed, retried, and accepted work is communicated, which actions remain safe, and how queues or in-flight requests drain. Pair the contract with a bounded journey that checks durable state. Assign ownership for interpreting capacity evidence and updating the case.

  3. Recheck after shared-limit changes

    Review the burst case after route mix, connection limits, worker settings, queue consumption, database access, or retry logic changes. Compare steady, burst, and recovery behavior again. Add a distinct load shape when a new critical workflow has a different concurrency or durability risk.

What to carry forward

The learning record should retain the burst shape, saturated boundary, overload semantics, recovery contract, and recurrence trigger. It is complete when future engineers can reproduce the observed capacity limit and can distinguish higher throughput from safe handling of delayed or rejected work.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow