{"id":848503,"date":"2026-03-25T03:46:28","date_gmt":"2026-03-25T03:46:28","guid":{"rendered":"https:\/\/www.europesays.com\/uk\/848503\/"},"modified":"2026-03-25T03:46:28","modified_gmt":"2026-03-25T03:46:28","slug":"qcon-london-2026-shielding-the-core-architecting-resilience-with-multi-layer-defenses","status":"publish","type":"post","link":"https:\/\/www.europesays.com\/uk\/848503\/","title":{"rendered":"QCon London 2026: Shielding the Core: Architecting Resilience with Multi-Layer Defenses"},"content":{"rendered":"<p><a href=\"https:\/\/qconlondon.com\/speakers\/andersonparra\" rel=\"nofollow noopener\" target=\"_blank\">Anderson Parra<\/a>, Staff Software Engineer at SeatGeek, presented <a href=\"https:\/\/qconlondon.com\/presentation\/mar2026\/shielding-core-architecting-resilience-multi-layer-defenses\" rel=\"nofollow noopener\" target=\"_blank\">Shielding the Core: Architecting Resilience with Multi-Layer Defenses<\/a> at <a href=\"https:\/\/qconlondon.com\/\" rel=\"nofollow noopener\" target=\"_blank\">QCon London 2026<\/a>, where he discussed strategies on how to handle significant traffic spikes in systems that can overwhelm an even well-designed infrastructure.<\/p>\n<p>Parra kicked off his presentation by describing the environment in which SeatGeek operates. This included what Parra characterized as a &#8220;traffic stampede.&#8221; The problem isn&#8217;t the traffic, he maintained, it&#8217;s when the traffic arrives faster than a system can adapt.<\/p>\n<p>As shown in the picture below, there are several signals that indicate when a system may collapse.<\/p>\n<p><img decoding=\"async\" alt=\"\" style=\"width: 600px; height: 350px;\" src=\"https:\/\/www.infoq.com\/news\/2026\/03\/shielding-the-core-parra\/news\/2026\/03\/shielding-the-core-parra\/en\/resources\/1infoq-systems-collapse-1774371374991.jpg\" rel=\"share\"\/><\/p>\n<p>The Noisy Neighbor Problem refers to a multi-tenant system where one tenant disproportionately consumes shared resources that degrades performance for other tenants.<\/p>\n<p>The Scaling Gap is defined as the period when scaling lags behind demand. Systems must survive the scaling gap, Parra maintained, and this is where shielding the core begins.<\/p>\n<p><img decoding=\"async\" alt=\"\" style=\"width: 600px; height: 346px;\" src=\"https:\/\/www.infoq.com\/news\/2026\/03\/shielding-the-core-parra\/news\/2026\/03\/shielding-the-core-parra\/en\/resources\/1infoq-scaling-gap-1774371374991.jpg\" rel=\"share\"\/><\/p>\n<p>The strategy to shield the core is threefold: Absorb the Burst by handling sudden traffic spikes before they reach core systems; Control the Flow that applies fairness, rate limits and admission control; and Protect the Core to keep critical services stable during demand spikes.<\/p>\n<p>The defense layer deployed by SeatGeek uses a multi-shield approach:<\/p>\n<ul>&#13;<\/p>\n<li>Edge Shied<\/li>\n<p>&#13;<\/p>\n<li>Gateway Shield<\/li>\n<p>&#13;<\/p>\n<li>Platform Shield<\/li>\n<p>&#13;\n<\/ul>\n<p>Edge Shield<\/p>\n<p>The responsibilities of the Edge Shield include: a Cache that serves requests without hitting the origin; a Queue to absorb sudden traffic bursts; and a Filter to detect bots and invalid traffic.<\/p>\n<p>Using the Cache as a resilience mechanism solves the issues of: fewer cache responses as a function of increasing failures; more origin traffic when there are fewer cache hits; and an increase in failures when there is an increase in traffic.<\/p>\n<p>Parra maintained that everything changes with a combined use of the cache with rate limiting. The service remains stable, the cache warms up safer, and there is a decrease in origin load.<\/p>\n<p>SeatGeek also implements a Virtual Waiting Room that absorbs the traffic and controls the flow.<\/p>\n<p>Gateway Shield<\/p>\n<p>The responsibilities of the Gateway Shield include: a Rate Limit that controls the rate of requests; Fair Access that protects legitimate users; and Validation that rejects invalid traffic.<\/p>\n<p>The use of rate limiting involves a Rate Limit Gate that protects the platform from overload. This allows client requests during normal traffic, but triggers an HTTP 429, <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/HTTP\/Reference\/Status\/429\" rel=\"nofollow noopener\" target=\"_blank\">Too Many Requests<\/a>, response when there are high spikes in traffic.<\/p>\n<p>Sources of traffic include: humans, fans who legitimately want to purchase tickets; and automated agents consisting of sophisticated bots and distributed automation. The SeatGeek Fair Access Policy involves rate limits by: users and their respective accounts; and consumers with their respective API keys. Limits by IP address are used as a fallback.<\/p>\n<p>Platform Shield<\/p>\n<p>The responsibilities of the Platform Shield include: Resource Isolation that applies CPU limits, schedules priorities and prevents noisy neighbors; Prioritization that protects critical paths; and Observability Signals that utilizes a queue, CPU saturation and uses scaling signals.<\/p>\n<p>Parra described a scenario of three services (labeled A | B | C) and compared them with, and without, isolation and the subsequent cascading events (or Noisy Neighbor Problem) when service A is affected. Without isolation, when service A suffers a significant increase in CPU time, service B suffers from an increase in latency followed by a collapse in service C. Conversely, limiting CPU time in service A provides stability in both service B and service C.<\/p>\n<p>Mapping the Flow of Signals and Scaling includes:<\/p>\n<p>Spike in traffic &#8211;&gt; Increase in queue size (a signal) &#8211;&gt; Reaction by the scaling mechanism (invocation of the Horizontal Pod Autoscaler (HPA)) &#8211;&gt; Increase in capacity (more available pods) &#8211;&gt; a decrease in queue size.<\/p>\n<p>Signals originate from all three layers of the SeatGeek defense system. Parra stated that a resilient system depends on early signals, and that every system needs signals. This provides a faster drain of the queue size shown in the Flow of Signals and Scaling.<\/p>\n<p>The Four Core Principles include: Composition where resilience is layered; Protect the Core to preserve critical paths; Observe Pressure because signals reveal stress; and Controlled Failure to fail gracefully, if necessary.<\/p>\n<p>The best signals appear before failure, and Parra concluded by stating &#8220;Internet stampedes are inevitable; system collapse, however, is not.&#8221;<\/p>\n<p>More details on this topic may be found in this <a href=\"https:\/\/chairnerd.seatgeek.com\/shielding-the-core\/\" rel=\"nofollow noopener\" target=\"_blank\">white paper<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"Anderson Parra, Staff Software Engineer at SeatGeek, presented Shielding the Core: Architecting Resilience with Multi-Layer Defenses at QCon&hellip;\n","protected":false},"author":2,"featured_media":848504,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_share_on_mastodon":"0"},"categories":[7757],"tags":[30172,748,12495,22486,242330,393,4884,257,238729,119242,8720,27960,242329,16,15],"class_list":["post-848503","post","type-post","status-publish","format-standard","has-post-thumbnail","category-london","tag-architecture-design","tag-britain","tag-development","tag-devops","tag-distributed-cache","tag-england","tag-great-britain","tag-london","tag-qcon-london-2026","tag-queue","tag-resilience","tag-scaling","tag-shielding-the-core-parra","tag-uk","tag-united-kingdom"],"share_on_mastodon":{"url":"https:\/\/pubeurope.com\/@uk\/116287765621100753","error":""},"_links":{"self":[{"href":"https:\/\/www.europesays.com\/uk\/wp-json\/wp\/v2\/posts\/848503","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.europesays.com\/uk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.europesays.com\/uk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/uk\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/uk\/wp-json\/wp\/v2\/comments?post=848503"}],"version-history":[{"count":0,"href":"https:\/\/www.europesays.com\/uk\/wp-json\/wp\/v2\/posts\/848503\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/uk\/wp-json\/wp\/v2\/media\/848504"}],"wp:attachment":[{"href":"https:\/\/www.europesays.com\/uk\/wp-json\/wp\/v2\/media?parent=848503"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.europesays.com\/uk\/wp-json\/wp\/v2\/categories?post=848503"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.europesays.com\/uk\/wp-json\/wp\/v2\/tags?post=848503"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}