Peak season does not invent new bottlenecks so much as it reveals the ones that were polite under ordinary load. Six weeks out is a workable window for application architecture analysis aimed at performance bottlenecks — long enough to measure, short enough that the architecture will not have reinvented itself.
Prioritize the three journeys that carry the most revenue or regulatory weight. Measure them under a load that resembles last year’s peak, not a synthetic spike that no user path would produce. Separate capacity limits (not enough workers, disk, or connections) from design friction (chatty calls, shared locks, cache stampedes).
Design friction rarely yields to ‘add more of the same.’ Capacity limits sometimes do. Mixing the two in one recommendation list wastes the weeks you still have. Rank by expected impact on the journey, then by effort your team can complete before the peak date.
If metrics access is incomplete, say so early. A bottleneck assessment that guesses from incomplete graphs is worse than a shorter assessment that names the missing measurements as open risks.