Cloudflare edge engineering
Cloudflare usually gets bought for one of three reasons: the site feels slow, the bots are winning, or the DNS is a mystery nobody documented. Only some of those are edge problems.
01Capabilities
What changes when a proxy sits in front
Cloudflare sits between your visitors and your application, which makes it powerful and makes it easy to hide a problem behind. We treat it as one layer of a cloud infrastructure design rather than a product to switch on, and where the fix belongs at the origin it is engineering work instead. Four shapes.
- Caching
Rules that reflect what is genuinely shareable
Which means auditing your responses first. Cookies set on every page, no-store headers copied from a tutorial, and personalized fragments inside otherwise static pages each quietly defeat a cache, and one of them makes caching dangerous rather than useless.
- Abuse
Blocking unwanted traffic without blocking customers
Managed rules, custom rules and rate limits for credential stuffing, scraping, and checkout and signup abuse. Common in e-commerce work, where the expensive failure is a real customer refused, not a bot getting through.
- Workers
Small pieces of logic that run before the origin
Redirects, header rewrites, authentication checks, split tests and light transforms, handled before a request ever reaches your servers. Small and well-scoped is excellent here. A whole application at the edge is a platform commitment, and we treat it as one.
- DNS
Moving a zone without an outage
Taking over records nobody can account for, keeping mail authentication intact, and rehearsing the way back. DNS is the cheapest place on the internet to cause something that looks to your customers like total failure. Where a zone move is part of a wider platform decision, that is cloud consulting.
02Fit
Caching is a correctness decision first
The interesting question at the edge is not how fast a response arrives. It is whether the response a stranger receives was ever meant for them. Get that wrong and the quickest page on the site is somebody else's account page, served from a cache to everyone who asks. Five of the six rows below send you somewhere other than a Cloudflare project with us, and three of them name no unicrew page at all.
| Your situation | What we recommend |
|---|---|
| A global audience, genuinely public content, and an origin in one region | Use CloudflareDistant visitors wait less and your origin stops sending the same bytes over and over. This is the straightforward case. |
| Pages that vary by signed-in visitor, or a cookie set on every request | Cache nothing yetAudit what varies before one rule goes on. A cache that cannot tell two visitors apart will eventually show one of them the other's page. |
| The application is slow because of queries, access patterns and missing indexes | Fix the originNothing can cache a page that has to be built per person. That is engineering work, and the measurement that proves it takes about an hour. |
| You already run CloudFront and a firewall on AWS, configured and understood | Do not stack a secondTwo caches and two rule sets mean two places to debug every incident, for no gain anyone can point at afterwards. |
| You want to move meaningful application logic into Workers | Be selectiveEdge-shaped work fits well. Long-running or stateful services belong in containers at the origin, and moving everything is a commitment with real limits. |
| Regulated data that has to stay inside one jurisdiction | Start from the ruleSettle where traffic may be terminated before anything is proxied. Sometimes the answer is one region, and sometimes it is not a public edge at all. |
Scope
We own the whole request path here, not the dashboard. That means what is shared and why, what visitors see when your origin is down, and whether one rule change can lock out real customers. It also means how a cache or DNS change gets undone under pressure. unicrew has built and run systems like this since 2012. We have 100+ senior in-house engineers across six countries. We work under an ISO 27001:2022 certified information-security management system. We own telling you when the edge is the wrong layer, which is the most common finding on performance work.
Putting something in front of your application is the cheapest performance work available and the easiest to get subtly wrong. Caching is a correctness decision, not a speed one: the moment a cached response can be somebody else's, you have a data problem rather than a latency problem. We would rather spend an hour on what must never be cached than a day tuning what should.
Ihor PrudyvusDelivery Director, unicrew03Delivery
Turning the edge on without breaking a customer
Every step exists to stop a change here from becoming an outage or a quiet regression nobody notices for a month.
- Measure where the time actually goesSplit the request: name lookup, connection, the wait while your server thinks, and transfer. That breakdown decides whether the edge helps at all, and it takes hours rather than days to establish.
- Audit what is shareable before sharing anythingWhich responses are safe to serve to a second visitor, for how long, and what varies them. Session cookies on static files and unnecessary Vary headers are the two usual reasons a cache appears to do nothing.
- Run new rules in log-only mode firstManaged rules, custom rules and rate limits record what they would have blocked, against real traffic, before anything is enforced. This is how you find the integration partner your new rule was about to cut off.
- Cut over DNS deliberately, with a way backLowered lifetimes ahead of the change, mail and verification records confirmed, the switch made inside a known window, and the previous zone kept ready. Lifetimes go back up once it is boring. The pipeline side of this sits in DevOps consulting.
04Stack
What sits behind the proxy
The four neighbours of an edge decision, each with its own page if that is the call you are really making.
05Questions
Questions about putting something in front of your origin
The six that come up before a domain is pointed anywhere new. If yours is not here, it is a good first message.
Yes, and edge work often runs that way, because the decisions touch your DNS, your security posture and your release process at once. What we will not do is supply hands and leave the request path unowned, which matters here because a bad rule fails for everyone at the same moment. Capacity is managed teams; the outcome is DevOps consulting.
For visitors far from your origin fetching shareable content, yes, and noticeably. For a signed-in dashboard whose slowness comes from queries, no, and the measurement usually shows that within an hour. That is why we split the timings before recommending anything. If most of the wait is your server thinking, an edge cannot help and buying one only moves the conversation.
If your platform is already on AWS and your team knows it, CloudFront keeps one account, one bill and one permissions model, which is worth more than any feature comparison. Cloudflare tends to win where the estate is mixed, where you want name service, firewall, bot handling and edge compute from one place, and where flat pricing is easier to predict. Running both is the actual mistake.
Only when you have proved what varies, and most teams have not. The failure is not a slow page, it is one visitor being served another's content, and it is usually invisible until somebody reports it. We audit cookies, headers and personalized fragments first, then cache the parts that are genuinely shared and leave the rest alone. That audit is a day, and it is the cheapest day on the project.
For edge-shaped work, yes: redirects, authentication, header and image transforms, split tests and small APIs close to the visitor. For your core application, ask what happens when you need a long-running job, a heavy dependency or a transactional database, because those are where the model pushes back. We will build on Workers where the shape fits and say plainly when a container at the origin is simpler.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we offer it once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer. Most engagements start within two to four weeks.
Unsure whether the edge is the right layer?
Send us the domain and a description of what you are seeing. You get an engineer's read on which layer the problem is really in, and what we would change at your origin instead.