📝 Add documentation for spike protection (#5791)

Author: leeandher

src/docs/product/accounts/quotas/manage-event-stream-guide.mdx

@@ -111,6 +111,60 @@ To review the error events dropped because of spike protection, go to the "Usage
 
 Events will not be dropped during any minute in which you don't send more than the hourly limit that Sentry has calculated for you. After 24 hours without any dropped events, spike protection becomes "inactive" again. This means that it is no longer dropping events, but _it does not mean the system has stopped paying attention._ The next time events are dropped, spike protection will be "reactivated".
 
+### New Heuristic Changes
+
+<Include name="limited-avail-note.mdx" />
+
+Spike protection is enabled for every project by default, and when it's enabled, Sentry continually monitors for spikes. You can confirm that it's enabled in **Settings > Projects > _Select Project_ > General Settings**.
+
+The way our spike protection algorithm essentially works is by using a weighted average of your events over the past 168 hours (past 7 days), applying a multiplier to that number, comparing this final number against a floor bound that is determined using your quota, and setting that as your spike limit.
+
+### Spike Protection Inputs
+
+- Number of projects
+- Quota (per event type)
+- Events in the past 7 days
+
+### Floor Bound Calculation
+
+To break it down even further, the first step of this algorithm identifies a floor bound that is calculated using your quota. This bound takes the max of either 500 events or (3 \* your quota)/(720 \* number of projects) - the latter number represents your project using up 3 times your overall quota in 30 days if events are continually ingested at this hourly rate, thus flagging for a potential spike.
+
+### Spike Limit Calculation
+
+The next step uses hourly data from the past 7 days to calculate spike limit projections for the next 7 days. This data is used to calculate weighted averages, which takes into account weekly and hourly seasonality. For example, the weighted average calculated for Monday at 3 pm is more heavily influenced by data points on Monday or hours around 3 pm. This weighted average is then multiplied by a multiplier that is 5 times the overall standard deviation of the past week - this multiplier is bounded between 3 and 6.
+
+### Setting the Final Limit
+
+The final spike limit for each hour is set to the max of the floor bound or the calculated limit. This is done for a multitude of reasons - firstly, using the floor bound protects smaller or new projects. New projects that do not have a week’s worth of data to use to calibrate spike limits can use the floor, an adaptation of the organization’s quota, to approximate appropriate limits. Additionally, the floor can be used to minimize false positives in smaller/new projects such that spikes aren’t flagged incorrectly.
+
+Additionally, at the onset of a spike, spike limits are recalculated in real time throughout the duration of the spike. While this is done to adjust for the increasing volume of incoming events, the limit grows at a steady rate such that quota is protected and not blown through. An example of how our heuristic works during a spike is shown below.
+
+### **Example Calculations**
+
+![Spike zoomed out](spike-protection-zoomed-out.png)
+
+![Spike zoomed in plotted with spike limits](spike-protection-zoomed-in.png)
+
+**_During Spike_**
+
+- 1st hour: 6k events ingested, limit is recalculated to 2083, 3917 events dropped
+- 2nd hour: 34k events ingested, limit is recalculated to 2873, 31217 events dropped
+- 3rd hour: 55k events ingested, limit is recalculated to 5452, ~49k events dropped
+- 4th hour: 49k events ingested, limit is recalculated to 7628, ~41k events dropped
+- 5th hour: 41k events ingested, limit is recalculated to 9371, ~31k events dropped
+
+Limits are recalculated throughout the duration of the spike.
+
+For this particular example:
+
+- Org Quota: 500k
+- Events Ingested: ~478k
+- Events ~157k
+
+Here's an example of spike limit projections for a week, taking into account seasonality:
+
+![Spike limit projections with seasonality](spike-protection-steady-state.png)
+
 ## 2. Adjusting Quotas
 
 <Note>