6 architecture patterns that repeat across enterprise customers

My name is Damiete King-Harry. I'm a solutions architect at Cloudflare. My day job is to basically speak to large, complex organizations, typically based in Europe, Middle East and Africa, about all sorts of things, design patterns, recommendations, best practices, how to build Oracle Cloudflare, etc. And these organizations typically have different profiles, they have different constraints, they have different operating models. But then you'd notice that there are some things that repeat across these organizations. Some of them are what I like to call patterns, or more specifically, they are anti-patterns. So things that you probably shouldn't be doing when you're thinking about technical design, when you're thinking about systems architecture. So I brought six examples with me. I'm going to talk you through the way I think about talking to customers that I think about solving these problems. And I might be able to ask some of these questions within your own architectural patterns, and hopefully learn one or two things that you may not have learned. So the four things I take a look at when I talk about the sorts of things that customers are on intent, what is it trying to do? How are you going to control it? What is it? And then what proof do you actually have that what you're trying to do works, right? The proof for me is the biggest key point, right? So without further ado, we'll take you through the six decisions, right? The first is on identity, not being an authorization key. Origin of problems is the second. The third decision model is our shared policy and control exceptions. The fourth decision is about caching, the fifth is about work storage. And of course, the last but not the least, the most important is on resilience and how that is managed as well. So we'll go through the first one really quickly because for whatever reason, time flies away. So valid identity not being a way to manage security. This comes from organizations that undergo digital tax primarily, low-level scrapes, anything that is automated. Most customers, most organizations try to think about security proactively. Why would you do that, right? You build out a domain or a platform, you build out a domain anywhere else, you may think about security controls you put in place. One of the things that you do is to create rate limiting rules, right, for no slow attacks. Organizations don't typically use IPs as rate limits because why would you? It's 2026, everyone shares IPs, IPs are cheap enough. So what organizations tend to do is to create rate limits based on session identifiers, right? Rate limits on headers, rate limits on cookies. Let's make sure that we have a way to identify malicious attacks. But unfortunately, when they do that, what tends to happen is your attackers are not silly as well. They are able to create their own session identifiers, they're able to understand your buckets, and they end up making sure that your legitimate users get trapped in your buckets while they fly under the radar. My recommendation for customers such as this is always think about narrowing down as much as possible the lowest-net of enforcements to make sure that malicious actors get caught while legitimate users go through. So rather than rate limiting just on a session ID, you can narrow that down for the session identifier tied with the HTTP method, tied to the endpoint, tied to a J4 fingerprints, perhaps tied to a country of origin, or perhaps tied to a device identifier, right? You end up making the attack more expensive for the attacker. When an attack is too expensive for your attacker, they will move on, right? So if you ask the question at the bottom there early enough, what identity is authoritative, what is visible on every path, and what is costly for your attacker to repurpose, answering that question before you design a security pattern helps us to ensure a successful security architecture. So that's one example of how questions help you get to and after. The second one is on origin provenance. This is a typical design pattern for organizations behind a reverse proxy. It tends to typically have every connection to the origin authenticated, right? Either you have an ID allow list, or you have MTLS between the edge and your origin, or you use a tunnel between the edge and your origin, right? But if you don't think about provenance means on every hop, you run to a situation like this customer did, where obviously complex organizations have different teams managing different origins, right? So team A has an IP allow list, team B have a certificate, team C have a tunnel, right? Team X allow anyone from within the network access to that origin, right? So whilst they secured all the entry points from the edge through to the origins A, B, and C, the fact that they are in the same network with a different origin means that there is an accepted trust, right? And in today's world, if you think about what Zero Trust means, you shouldn't accept requests blindly even if it comes from the same network, right? So that was a fault that they failed in the audit process simply because they allow requests from within the same origin access to an origin that wasn't controlled for when building the connections from the edge to the origin, right? So that question needs to be asked that early. As an example, what control rejects unintended requests at every degree? It should help them get through to the competition that we got there, all right? The third item is on policy parity. Many organizations think about working with modern tools, right? You don't go into the dashboard and click around often. You use Terraform, you use Pulumi, whatever your code of choice might be. And you run into situations where you have organizations with central security teams that enforce baselines across the org, right? But they run into friction with application owners that wish to make changes and make them really quickly. In the example I pulled this from, the application team thought and override, according to their logic, meant to merge their changes into the central security policy. But override actually on platform means that you are replacing some, right? So coming from a different platform and not understanding the language of the platform we're moving to is typically failure number one. You could argue that it's also a failure of the engagement model. But what then ended up happening with the organization was they overrode their security policy. Luckily, this was caught on pre-prod. Override their security policy before it's pushed out. It would have been a catastrophic failure for the entire security org if that wasn't caught in time. So the question we should ask always or these sorts of multiple organizations dealing with different security policies or with the central org on top is to think about what shared intent means, is to think about how you will compile and control it, and is to think about, of course, who knows the tech dangers. Because there is another example where an application owner perhaps responding to, again, a lot of attack scenarios, in the morning, bypasses the Terraform config, goes into the dashboard, creates a click rule, and then forgets to check that back into Terraform. Six months later, no one knows why that rule is in there because it seems to have been withdrawn. That is a full-level process. So this is the sort of thing that if there is an owner, as I said, we want intent, mechanism, ownership, and then post, this gets deployed into production. The fourth is about cache management, things that need at your reverse proxy's edge. In the last 12 to 18 months, I've seen a lot of these recently where you have organizations that perhaps want to return different kinds of contents to crawlers, to OpenAI, to Anthropic, just to, because they think it helps them surface when these are searches for, I don't know, for sneakers, as an example. They believe that you can return things at the edge as quickly as possible. You can return specific types of contents, return contents in a local language to the agents differently than you would to normal. That helps them get higher in your rankings. And I have seen two organizations that have gone ahead to build an app that from workers that reach out to their origin to fetch everything on the sitemap, right? What ends up happening with these organizations is they basically de-dust themselves. Because when you create a worker, once you've got a file size edge to reach out to your origin to fetch every single thing that you might have, every single path available, you have to ask yourself questions like, are these assets even cacheable? Why are you requesting for assets to be in cache when these assets are dynamic anyway, right? You make a request to API endpoints that are not going to be in cache, the agents are not interested in. So thinking through the questions, what is cacheable? Who owns it? Where is everyone? Who owns the control from the origin? How do we measure failure? Asking these questions, before designing what these policies look like, help make sure that you don't de-dust yourself into oblivion, all right? The fifth architectural path and I have seen all this news on storage, new engagements, when customers come to us, one of the things they say is, I want to send everything to my seat, right? Just send everything. You know, that's really intense, right? But if you think about the mechanism and the ownership of that, it then becomes painful because along that path, when you think about the ownership, yes, you have a platform, yes, you have a SOAP, yes, you have compliers, but then you also have ownership from the finalists who at the end of the month ask you why the data storage bills have gone through, right? So again, questioning to see how, which responders must act quickly. What are you interested in? Are you interested in logs or are you interested in metrics, right? Because there are different ways to slice whatever you're looking for. If it's for native quick search, instant response processes, we need to respond in Windows. There are different metrics being pulled easily for that, right? If it's for your SOAP team that needs to respond in days to weeks, there are different ways to pull that kind of data. And if it's for compliance for long-term storage, it can fetch you perhaps more slowly. You probably don't need every single field platform that has to sail through to your origin and you can store that as cheaply as well. So asking that question early enough helps you think about what the storage architecture is rather than mostly to down the line until a bill comes in from Splunk or from Datadog. And then the final thing is actually one of the most important ones, which is about resilience. In Europe especially, we have a lot of compliance requirements that have been pushed out. So if you think about things like DORA, if you're working with financial services, there's a lot of regulations around making sure that you have multiple vendors for the same problems, right? So I have a lot of message and I'm thinking about having multiple WAFs, multiple CDLs, et cetera. And the problem with this is you might have an application that you're having vendor B ask the backup vendor. Vendor A runs traffic 100%, vendor B is the backup, you build the config, you're very happy, right? But what you haven't accounted for is the failure model. What happens when you need to failover to vendor B and so they will find out all your TLS certificates have expired on that vehicle, right? That's what a lot can account for. What happens when the DNS that needs you to vendor A goes down? Without DNS, nothing else happens in that chain. Without resilience and DNS, everything else is also a failure, right? So if this question is asked, what failure are we diversifying for? Who owns it? How do we measure it, right? Without the measurements of these things, everything that you're building as a design item is simply a theory waiting for you to disprove it, okay? So thinking about the intent, resilience mechanism, the ownership, and the failure model helps you to get to the outcome for successful resilience. And then thinking about these patterns from one to six that I've just gone through and applying this to the age of the genetic Internet where we are, this is a worked example some time I worked with a customer a couple of weeks ago where the thing about the question is the scenario was there's a sign-in customer and an application team has built out and they ask for agents. Obviously, there's a different ownership for the refund service and a different ownership for the gateway service. What happens when a sign-in customer asks for a refund, right? It's meant to trigger the agent. Agent hits the refund service pipeline, fetches the refund, pays it into the URLs, pays it back into the account, right? But the ownerships are there, but the proof methods are different, right? Because for the payment system, what their interest is is make sure that there isn't a duplicate payment. So there's a timeout along the path. They don't want to pay an account user two times. The refund service doesn't want to pay the refund to the wrong account. And the person that built or the team that built the AI support agent wants to make sure that you don't flood that agent with prompt injection attacks or whatever it might be to bring them down. So asking the questions at a big volume, something as simple as if the agent makes the wrong decision along this way, along the pipeline, what can it actually do, right? Just that simple question helps you to design an architecture that is successful against any failure in that pipeline, all right? So six steps that I typically go through is about configuration and reachability. Configuration simply means the setting is there, right? You've created the config, you've created the role, that's your standard. Reachability, yes, the configuration succeeds. But those two are basically steps along the way, all right? The other four are the most important for me. You exercise it regularly, you test it regularly, you measure your time to recovery, and then you regularly retest it, right? What I do most in this process is with my customers, with organizations I speak to, we often find that we find failures along the path that we then redesign for. So six questions on the board for the six patterns I broke, but these are not the six questions for me particularly. These are examples of questions that you should ask yourselves or your team as you go about what design looks like for your architecture, right? From identity through to resilience, from something low-level to something really, well, to high-level, always asking questions helps you to get to a successful end. So for your next design, for anything you build next, make sure you have an owner, make sure you write failure tests. And of course, since it isn't all, creating a bunch of failure tests should be quite easy for you. Feed it into your various agents and ask you to generate simple questions and simple tests for you, and that helps you design a better architecture. So when you're in-house, choose a mechanism, assign ownership, and make sure that you test, retest, and account for failure. That's my talk, so thank you.