Configuring Selectel CDN: Where Content Delivery Breaks
Peak load almost always reveals the same thing: static assets — images, fonts, scripts, styles — are served directly from the origin. While traffic is steady, this goes unnoticed.
As soon as a peak starts, the origin chokes: response time grows, some requests time out, and along with static assets, dynamic pages that have nothing to do with the cache slow down too.
Formally, static caching is “enabled” at the same time.
The problem lies in the details: caching headers are not set or contradict each other, markup parameters get into the key, making every address considered unique, and the file TTL is set so that the browser and intermediate node revalidate with the origin on almost every request. The cache exists but doesn’t hit — the origin sees the same flow as without it.
Then the second part comes in — slow content delivery on distant routes, where a request travels halfway around the world, and the lack of proper certificate handling at the network edge.
A certificate that is reissued manually and cache purge rules written “by eye” add a separate category of failures: after deployment, users see old files, and purging turns into a manual operation.
CDN configuration is not a single checkbox in the panel, but a set of decisions: what to cache and for how long, how the key is formed, how content is updated after release, and how the edge behaves when the origin is unavailable. Below we explain how this is addressed.
What Proper Cache and Certificate Configuration Delivers
A properly configured cache is not “set and forget,” but a set of measurable metrics. The cache hit ratio for static assets reaches 90% and above, the origin stops receiving repeated requests, and the page response time for a visitor approaches the latency of the nearest node. Below is the checklist we use to accept the configuration before commissioning.
- Cache hit ratio for static assets — from 90%: styles, scripts, images, and fonts are cached, not just page markup.
- Server offload: repeated requests are absorbed at network nodes, and the origin handles only misses and dynamic content.
- Content TTL is set by type: separate rules for versioned files and for pages with frequent edits.
- On-demand cache purge: invalidation by path or wildcard immediately after publication, without waiting for expiry.
- Smooth delivery during peaks: traffic is distributed across points of presence, and the origin doesn’t queue under load.
- Certificates: issuance and auto-renewal on the delivery network side, a correct chain of trust, redirect to a secure protocol, and no browser warnings.
We verify each item with a load test before switching traffic: we look at origin behavior under peak delivery and whether stability under load persists if one of the nodes fails.
We describe network configuration in Selectel as code — cache rules, headers, certificates, and domains are reproduced with a single command rather than assembled by hand in the panel, so staging and production do not diverge.
Selectel CDN: Comparison of Caching Modes
The caching mode is chosen before enabling delivery: it determines what will end up on edge nodes at all and what will continue going to the origin server.
An error toward “cache everything” breaks personalization and the cart, while the opposite error leaves the origin server under full load for media traffic.
Cache rules are set by paths, extensions, and request headers: static assets live at the edge, markup and API responses bypass it. Your own certificate does not conflict with the CDN — the chain is verified on the client side, and the domain remains bound to the current key.
| Option | When suitable | Limitations |
|---|---|---|
| Full-domain cache | Storefronts, catalogs, and promo pages without personalization | Need versioned URLs and cookie-based separation, otherwise a user may see someone else’s cart |
| Edge caching only for static assets | E-commerce sites, user accounts, services with APIs | Markup and API responses aren’t cached — gains only on media and scripts |
| Cache with key-based separation | Geo versions, personalized blocks, currency sections | Number of object copies grows, and hit ratio drops with minor differences |
| No cache, edge delivery only | User accounts, payment forms, reports | Load on the origin server doesn’t decrease, gains only in routing |
The selected mode is recorded in cache rules and versioned together with the configuration — then post-release purge remains predictable rather than a manual operation.
Implementation Procedure: From Audit to Handover
The work order is structured so caching and certificates are verified on a staging domain, not on production traffic. Each stage ends with an artifact — a scheme, configuration, or validation report.
- Configuration audit. We review content sources, caching rules, object retention periods at the edge, response headers, and the certificate chain. We find what is served bypassing the network and which file types are cached incorrectly.
- Content delivery scheme. We determine which domains and zones go through the network, where a direct origin remains, and how static and dynamic content are separated. The scheme captures the domain — zone — origin linkage.
- Rule configuration. We define caching by object types, cache bypass parameters, compression, security headers, and certificates for all names. The configuration is described as code and is validated before application.
- Cache validation. We run the staging domain: cache hit ratio, bypass correctness for authorized requests, file updates when the version changes. We make sure old static assets don’t stick at the edge.
- Rollback plan. We prepare a return to the direct origin: we save the previous domain records, their TTLs, and the order for returning certificates. Rollback takes minutes and does not require rebuilding the configuration.
- Traffic switch. We move records to the network, starting with one segment, and monitor the error rate and response time. If metrics deviate, we return via the rollback plan.
- Handover. We hand over the configuration, scheme, caching policies, and instructions for typical edits, plus metric thresholds at which intervention is needed.
Documentation and Configurations That Remain Yours
Everything we configure is handed over not via messenger chat but as working artifacts in your repository: the Selectel CDN configuration, schemes, and regulations that the team can use to change delivery without us.
The package is assembled so that a new engineer understands the scheme in one evening rather than reconstructing the logic from the edit history.
- Infrastructure scheme: domains, origins, delivery zones, statuses, and relationships between them — the diagram sits next to the code.
- Caching policies by content type: object TTLs, cache keys, bypass rules for dynamic content, behavior when the origin is unavailable.
- Descriptions of resources, certificates, and redirects as code — the environment is deployed from scratch repeatably, without manual edits in the panel.
- Access rules and roles: who can change what, where keys are stored, and how they are rotated.
- Update regulation: edit procedure, validation on the staging domain, acceptance criteria, rollback plan to the previous configuration version.
- Team instructions: certificate issuance, origin change, reading statistics, finding the cause of delivery errors.
- Decision log — why these TTLs and invalidation rules were chosen: in six months you won’t have to guess the logic from the change history.
Such a package removes the main risk: the configuration stops being one person’s knowledge and becomes part of your infrastructure.
Case Study: How Origin Load Was Reduced Severalfold
Starting Point
A catalog with heavy media content: images and video were served directly from application servers. Every navigation between sections went as a request to the origin, and during peak hours the server queued — some requests ended in a timeout.
Local caching on the application side didn’t help: the same files were rebuilt on every instance, and there were almost no hits.
What We Changed
We moved static assets and media to Selectel CDN and separated caching rules by content type: versioned files received a long TTL, catalog pages a short one, so edits quickly reached users.
The cache key was extended only with parameters that actually affect output — otherwise the CDN starts serving the wrong version of a page. The origin was closed to direct requests, and cache purge was tied to release deployment so it wouldn’t have to be cleaned manually.
Result
Cache hit ratio grew from one third of requests to nine out of ten — the origin stopped being a bottleneck. Load on application servers dropped by about five times, catalog response time decreased fourfold, and it stopped depending on the number of active users.
A separate class of failures disappeared: timeouts on media and delivery errors during sharp traffic spikes. Post-release cache purge no longer causes a spike in origin requests — warm-up is gradual, and deployment doesn’t take the service down.
How Does Edge Cache Differ from Browser Cache?
Browser cache lives on the visitor’s device: after receiving a response, the browser saves the object and on the next request doesn’t go to the network at all. Edge caching is a layer on provider nodes that serves the same response to hundreds of visitors before your server. These are two independent stores with different purge rules.
Both levels are controlled by the same cache headers — this is the main source of confusion.
An instruction set for the browser is inherited by the edge layer by default: either every visitor waits for the first load again, or a stale page gets stuck on nodes and isn’t purged on demand.
The levels are separated by directives such as s-maxage and private, as well as the Vary header — it describes which differences in the request make a response unique.
Cache TTL is set differently for the two levels. Static assets with a hash in the filename are cached long everywhere, while HTML responses usually get a short TTL at the edge and zero in the browser, so content edits are visible on the first page refresh.
Hence the configuration scheme: first mark responses that are the same for everyone, then set their edge TTL and purge-by-key rule, and shield personal data from the shared cache.
In Selectel CDN, purge works at the edge, but the browser cache of visitors who have already loaded cannot be purged: you can only wait for the TTL to expire or change the filename on deployment.
Technical Doubts Before Starting Work
Doubts before starting are usually not about “does content delivery work” but about operations: what will happen to stale cache, how the DNS switch will go, whether the platform will accept our certificate, and how to make sure everything is configured correctly. We address the four most frequently asked questions.
Will users see stale cache after release?
Cache is controlled by two levels: the object TTL on the Selectel platform side and purge rules. Static assets with a hash in the filename can be kept for a long time — their content doesn’t change.
For pages and API responses, we set a short TTL and add purge by tag on deploy: the build publishes a new set of files and invalidates only changed paths, not the entire cache.
This way the release is visible immediately, while hot objects remain cached and are not rebuilt from scratch.
Will the domain switch happen without downtime?
The procedure is: first create the delivery and bind the domain, check responses via a temporary address, then change DNS records, and only after that disable the old origin. We reduce record TTL in advance so the switch propagates across resolvers in minutes, not days.
The reverse rollback is returning the previous records; it takes the same amount of time and does not require reconfiguring the delivery.
Can we connect our own certificate instead of the platform one?
Yes, and this is a common case when the certificate has already been issued by a corporate center or covers several domains at once.
We upload the full chain together with intermediate certificates — if the intermediate link is omitted, browsers will show a warning even though the server-side check passes.
Then we configure automatic renewal and make sure the new certificate enters delivery before the current one expires.
We already have delivery deployed — will it need to be redone?
No. We start with an inventory: we capture the current caching rules, headers, domain bindings, and certificate settings, then transfer them via a configuration description.
Validation follows a checklist — response codes, cache header correctness, cache hits and misses, behavior when the origin is unavailable. Discrepancies are visible before the traffic switch, not after.
Let’s Discuss Your Task and Come Back with a Plan
To make the work estimate based on facts rather than assumptions, to start it’s enough to describe the task in free form: what you deliver, from where, and what load you expect.
We’ll clarify the details ourselves later, but a few inputs save a whole round of correspondence and one estimation iteration.
- Domains and zones that will go through CDN, and where DNS currently lives.
- Content origins: servers, object storage, or external services from which CDN pulls data.
- What is cached and what must bypass the cache: static assets, images, video, API, authorized requests.
- Certificate requirements: your own or provider-issued, whether a shared certificate for subdomains is needed.
- Access: a cloud account and a separate service user with rights only to CDN and DNS, not a master key.
- Change regulation: windows during which traffic may be switched, and tolerable downtime.
In reply, we send an implementation plan with the work order: stages, what exactly changes at each, rollback points, and who is needed from the customer side.
As a separate block — a Terraform configuration description and caching rules, so the configuration can be rebuilt and handed over to your team.
If some data is still unknown, that’s not a reason to postpone. Describe the task as it is, we’ll assemble an estimate and come back with a plan and substantive questions.