Transparent Edge ahead of your current CDN

Many websites and web applications have been running on a CDN for years, and it works well. The configuration is tried and tested, the team knows the dashboard, and the service is responsive. Over time, the bill grows at the same rate as the traffic, because the provider charges per gigabyte delivered, and the cloud charges for every byte that leaves the source.

In this case, the Transparent Edge CDN is placed in front of the existing CDN. Its nodes serve users and only query the other CDN when an object is not cached. You keep your provider, origin, and configuration, and reduce the traffic passing through the most expensive part of the chain.

Talk to an expert

Use case

The challenge

The current CDN is reliable, but expensive. Each request generates a costly transfer: the CDN bills for the traffic it delivers to users, and the cloud provider bills for the egress to the CDN. Switching providers abruptly requires migrating rules, certificates, and caching logic on a production site.

The CDN bill increases with each gigabyte delivered, even though thousands of users receive the same content.
Egressing from the cloud to the CDN adds a second cost for that same content.
Cache failures multiply requests to the origin and outbound traffic.
Traffic spikes, such as breaking news or a campaign, cause spending to skyrocket on specific days and make it difficult to predict.
A complete migration requires engineering time and a window of risk that many teams cannot afford.

The Transparent Edge approach

Transparent Edge acts as the first delivery layer. Its nodes respond to users, and your existing CDN becomes the origin for Transparent Edge. If the object is in Transparent Edge’s cache, the request doesn’t reach the other CDN. If it’s not, Transparent Edge requests it once, stores it, and serves it in subsequent requests. The platform coexists with other CDNs, so the current architecture remains unchanged, with no modifications to the client’s platform. Each provider has its own price per gigabyte, and with this model, most of the traffic passes through the provider with the lowest price.

Implementation of the multi-CDN strategy

Analysis of current traffic and configuration. Our engineers review what is currently cached, with what time-to-live (TTL) values, what headers the origin sends, and what content is dynamic.
Site setup using the current CDN as the origin. The visual setup wizard allows you to create and configure the site with just a few clicks, resulting in less setup time and less reliance on the technical team.
Rule migration. The team translates the cache, redirection, and header rules from the other CDN into the Transparent Edge configuration.
Hit ratio-oriented caching policy. TTLs and variants are adjusted per header (Vary), and dynamic content is cached using tag-based purges and query string normalization, which propagate in less than half a second.
Gradual DNS change. Traffic moves in parts, starting with subdomains or sections, and each step is validated before the next.
Production monitoring. With real traffic, we review hit ratio, requests to the source CDN and outbound traffic, and adjust the configuration.

Two add-ons: mid-tier and Sentinel

Mid-tier

It’s a second caching layer between the Transparent Edge edge nodes and the origin CDN. Only the mid-tier servers communicate with this CDN, so requests arriving from many nodes are grouped, further reducing the number of queries to the origin CDN. This is particularly useful when dealing with long-tail content, with many infrequently requested objects.

Sentinel

It unifies log observability in one place. With two CDNs in the chain, having the logs together allows you to see what’s being served from each layer, where cache misses occur, and how much traffic is reaching the originating CDN.

Our actions produce results

With Transparent Edge in place, most requests are resolved on its nodes. The previous CDN only receives cache misses, thus reducing its billing volume and, consequently, the egress traffic from the cloud to that CDN. Transparent Edge estimates savings of between 35% and 45%, depending on the scenario. The final figure depends on the amount of cacheable content and the price per gigabyte from each provider. Therefore, improving the hit ratio is just as important as the architectural change itself.

The origin receives fewer requests, and traffic spikes are absorbed at the edge, without significant investment in the origin infrastructure. The trusted CDN remains in the chain, and the client’s technical team retains control: they review traffic, purge content, and modify rules from the dashboard, with Transparent Edge engineers familiar with their configuration.

Recommendations

If your case is similar to this, it’s best to start with the data you already have:

Separate the CDN delivery cost and the cloud egress cost on your bill. This way you’ll know which part can be reduced.
Measure the hit ratio and outbound traffic from the source. Egress reveals more about the cost: with large, uncached objects, a high hit ratio still generates a bill.
Identify what content is cacheable: images, static files, repeated API responses.
Estimate the bill for the new string using your actual logs, including cache misses and spikes.
Start with a domain or section with a lot of cacheable traffic and expand later.

What can Transparent Edge do?

We’ll guide you with our team’s expertise to place Transparent Edge in front of your CDN, without altering what’s already working, and with caching adjustments tailored to your traffic and business needs. Our engineers provide support in both Spanish and English, are platform experts, and will work with you from day one.

Talk to an expert