0:02My name is Damir Teking-Hari. 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 our Cloudflare, et cetera. And these organizations typically have different profiles, they have different constraints, they have different operating models, right? But then you'd notice that there are some things that repeat across these organizations. Some of them are, you know, what I like to call patterns or, you know, more specifically, they are anti-patterns, right? So things that you probably shouldn't be doing when you're thinking about technical design, when you think about systems architecture.

0:49So I brought six examples with me. I'm going to talk you through the way I think about talking to customers. I think about some of 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 the intent, what is it trying to do, how are you going to control it, what goes it, and then what proof do you actually have that what it tried to do works. The proof for me is the biggest key. call it, 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 from this is the second.

1:35The third decision model is shared policy and control exceptions. The fourth algorithm is about caching. Fifth is about work storage. And of course, the last but not least, the most important is on Resilient. So that is managed as well. All right. So we'll go through the first one. really quickly, because for whatever reason, time flies away. So, wanted identity not being a way to manage security. This comes from organizations that are on-the-go, data-type 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 on Cloudflare, 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 um organizations don't typically use ips as rate limits because why would you is 2026 everyone shares ips ips are cheap enough so what organizations tend to do is to create rate limits based on session identifiers right let's read them into our headers net predicting it's our 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.

2:48They are able to create their own social enterprise. 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 the legitimate users go through. So rather than regulating just on a session ID, you can narrow that down further. fire tied with the HTTP method, tied to the endpoint, tied to a J4 fingerprint, 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 an attacker, they will move on, right? So if you ask the question at the bottom there early enough, right, what identity is authoritative, what is visible on every path, and what is costing you through an attacker to repurpose?

3:43I'm answering that question. before you design a security path and help us to ensure a successful security architecture, right? 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 path for organizations behind the reverse proxy. It typically has every connection to the origin, you know, 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 day 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 active coins from the edge through to the origins a b and c the fact that they are in the same network with um a different origin means that there is a uh uh an accepted trust right and in today's world if you think about what zero trust means you shouldn't accept requests blindly because it comes from the same network right so that was the whole that they filled in the audit process simply because they allow requests from within the same origin access to an origin that was a control for when building the connections from the edge

5:13to the origin, right? So that question needs to be asked that early as an example. What control rejects unintended requests at every degree? What? It should have helped them get through to the conclusion that we got there, all right? The third active pattern is on policy parity. Many organizations think about working with modern tools, right? You don't go into the dashboard and click around. phone, 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 donors that wish to make changes that make them really quickly. In the example I pulled this from, the application team thought override according to their logic means to merge their changes into the central security policy the override actually or cloudflare means that you are replacing some right so coming from a different from a different platform and not understanding the language of the platform we're moving to is typically you know failure number one you could argue that it's also a failure of of the of the engagement model uh but what then another happening with organization is the overall of their security Luckily, this was caught on pre-prod, overriding security policy before it's pushed out.

6:37It 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, and 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 to think about, of course, will launch the tech tendrils. Because there is another example. where an application owner, perhaps responding to, again, a lot of attacks scenario in the morning, bypasses the Terraform config, goes into the dashboard, creates a click rule, and then forget to check that back into Terraform. Six months later, no one knows why that label is in there because it seems to happen with . That is the whole little process, right? So this is the sort of thing that if there is an owner, as I said, with an intent mechanism, ownership, and then proofs, this gets caught before it's the- go into production.

7:32The fourth is about cash management, right? 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 content to crawlers, right? To open AI, to Anthropic, just to, because they think it helps them surface when they search for, I don't know, for sneakers. as an example they believe that you can you can return things at the edge as quickly as possible uh you can uh return specific types of content which has a lockdown you know return content in the local language to examples differently than you were to to the agents differently than you were to know that helps them get um higher in your rankings and i have seen two organizations that have gone ahead to build on our platform workers that reach out to their origins to fetch everything on the sidemap, right?

8:27What ends up happening with these organizations is they basically DDoS themselves. Because when you create a worker, what you got fast for is it, switch out to your origin to fetch every single thing that you might have, every single path available. You have to ask you to a question that's like, are these assets even cashable? Why are you requesting for assets to be in cash when these assets are dynamic anyway, right? You're making requests to API endpoints that are not going to be in cash. are not interested in right so thinking still with the questions what is cashable who owns it where is everyone who owns the control someday from the from the origin how do we measure failure asking these questions at the outset before designing what these policies look like help make sure that you don't use the cell phone see into oblivion all right uh the fifth architectural pattern i have seen all this news on storage new engagements when customers come to us what i things they say is, I want to send everything to my seat, right?

9:25Just send everything. That's really intense, right? But if you think about the legalism and the ownership of that, it then becomes painful, because I'm not on that part when you think about the ownership, yes, you have a platform, yes, you have a stock, yes, you have compliers, but then you also have ownership from the finalists who, at the end of the month, ask you why the storage bills have gone through me, right? So, again, to see which responders must act quickly. What 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, internet response processes, we need to respond in Windows. There are different metrics going forward easily for that, right?

10:10If it's for your SOP 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, storage, it can fetch you perhaps for a slowly, you perhaps don't leave every single field Cloudflare has to you, send it through to your origin, and you can store that cheaply as well. So asking that question early enough helps you think about what the storage architecture is, rather than most of the two down the line until a girl comes in from Splog 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

10:48requirements that have been pushed down. 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, you know, multiple vendors for the same problems, right? So I have a level of message and I'm thinking about, you know, having multiple WAFs, multiple CDNs, 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've built the config, you're very happy, right? But what you haven't accounted for is the failure role. What happens when you need to fail over to vendor B and so it will find out all the TLS certificates have expired on that vendor, right? That's what a lot can accounted for. What happens when the DNS that leads you to vendor A goes down?

11:38Without DNS, nothing else happens in that chain. With that, we'll just listen to you. everything else is also a failure, right? So if there's questions at the outset, 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, the mechanism, the ownership, and the failure model helps you to get to the outcome for successful... successful resilience. I've been thinking about these patterns, you know, from one to six that I've just gone through and applying it to, you know, the age of the agentic internet where we are. This is a worked example, something I worked with a customer a couple of weeks ago, where if you think about the question is, the scenario was the sign-in customer and an application team has built out an AS for agents.

12:31Obviously, there's a different ownership for the refund survey itself. What happens when a 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 URLs 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 to click a payment. So there's a timeout along the path. They don't want to make sure to pay. a user, an account user of two types. The refund service doesn't want to pay the refund all to the wrong accounts. And the person that built or the team that built the AI support agent want to make sure that you don't flood that agent with, you know, prompt injection attacks or whatever it might be to bring them down.

13:22So asking the questions at a big one, something as simple as if the agent makes the wrong decision along this way, along the pipeline, what can it actually do? Right, just a simple question. Helps you to design an architecture that is successful against any failure in in that pipeline all right so six steps that i typically go through um there's about configuration and reachability configuration simply means the setting is there right you've created the company you've created the rule um that's your standard reachability yes the connection succeeds but those two are basically steps along the way all right the the the the other four are the most important for me you exercise it regularly you test it You measure your time to recovery, and then you regularly retest it, right? What I'd also do in this process is with my customers, with organizations that I speak to you, we also find that we find failures along the path that we then redesign for.

14:16So six questions on the board for the six patterns I brought, but these are not the six questions for me particularly. These are the examples of questions that you should ask yourselves or your team as you build out 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 man 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 is well creating a bunch of failure tests should be quite easy for you feed it into your various agents and ask you to generate simple simple questions and simple tests for you and that helps you uh design a better architecture so then you're already test, choose a mechanism, assign ownership, and make sure that you test, retest, and that can't have the failure.

15:02That's why I talk, so thank you.