What does the application's own session store show during a suspected flood that the edge access log cannot?

## Two vantages, two different facts An edge access log answers: *a request arrived, here is what I served, here is how long it took*. That is a per-arrival record. The application's session store answers a different question entirely: *did this arrival turn into anything?* Sessions carry forward — a state token issued and then presented again, a cart, a step counter in a signup flow, a search followed by a result click. The forward path is the part that is expensive for an adversary to fake and cheap for a real person to produce, because real people are trying to do something. So the shape signals, roughly in increasing strength: 1. **Depth.** Did the client request a second distinct path? 2. **State carried forward.** Was a session token issued and then presented on a later request? Did the client fetch the page's own subresources, which a browser does automatically and a bare request generator often does not? 3. **Completion.** Did any measurable fraction reach the thing the launch existed for — a purchase, a signup, a queue place? A flood shaped like growth typically shows a large arrival count with a forward path that is flat at zero. Arrivals that only ever arrive. ## The wrong answer this question is aimed at The competent-sounding answer is *bounce rate is 97 percent, therefore attack*. It is wrong twice. - **A real launch produces an enormous single-page cohort.** People arrive, see a countdown, see sold out, see a price, and leave. On a launch morning the honest bounce fraction can be terrible and the traffic entirely genuine. If you key the decision on the bounce fraction you will block your own launch. - **Your own client retrying looks like repeated first-page arrivals.** If a backend is slow and the mobile app re-issues the call, you get many arrivals for one path from clients that are unquestionably real. Those clients typically have valid prior sessions and history, which is exactly what a flood does not have. Blocking them turns a degraded service into an outage for the people you already had. The correction is that the discriminator is not the *fraction* that bounced but whether the cohort ever behaved like a client at all: did it accept and return state, did it pull the subresources, does it have any prior relationship with you. A genuine bouncer still did all of the first two. ## The direction of the claim Be precise about what a session record proves. A created session proves that a request was accepted and a token was issued — it does not prove a human was present, and an adversary willing to spend a little more can create sessions. Equally, the absence of completions proves nothing on its own about intent: if the launch page is failing for capacity reasons, genuine users cannot complete either, and you will read your own outage as evidence of an attack. Always check whether the forward path is empty because nobody is walking it or because it is broken. ## What this costs you This is the leaf's real tension, and an interviewer will look for it: | Cost | Why it bites on launch day | | --- | --- | | Latency of evidence | The application view lags the edge view. Sessions have to be created and then not followed up, which takes minutes you may not have before the fixed launch time. | | Access | Someone with production application or database access has to be on the bridge to read it, and on launch morning that person is usually busy shipping. | | Self-degradation | The session store is a resource the flood is filling. Under enough load it slows, evicts, or starts rejecting — so the measurement gets worse precisely as the situation gets worse, and low completion counts may reflect your own store failing rather than the traffic's nature. | | Sampling and privacy | If the store or its analytics are sampled, aggregated hourly, or stripped of the join key that would let you match a session to an edge record, the correlation you need may be impossible in the window you have. | ## Using it together with the edge view The two vantages are complementary and each covers the other's blind spot. The edge tells you the sources spread broadly but present very few distinct client fingerprints; the application tells you those arrivals never came back for a second thing. Either alone has an innocent explanation — your own mobile client explains the first, a sold-out page explains the second. Together, they rarely do, and that conjunction is what a launch-day owner should be looking for rather than a bigger number on a graph.