Instead of every request reaching the application's origin server, cacheable content is stored at edge locations around the world.
As a result, many requests are served directly from the nearest edge location, reducing latency, improving response time, and lowering the load on backend services.
CDNs are commonly used for images, CSS, JavaScript, videos, documents, and even cacheable API responses.
Why Do We Need a CDN?
Suppose a Spring Boot microservices application is deployed in the AWS ap-south-1 (Mumbai) region. Users in India experience good response times because they are geographically close to the application.However, users in Europe or North America must send every request across continents before reaching the origin server, increasing network latency even when the application processes requests quickly.
A CDN solves this problem by routing requests to the nearest edge location. If the requested content is already cached, the edge location returns it immediately without contacting the origin server.
How Edge Caching Works?
When a user requests a resource for the first time, the nearest edge location checks whether it already has a cached copy. If the content is available, known as a cache hit, it is returned immediately.If the content is not available, known as a cache miss, the CDN forwards the request to the origin server. The response is then cached at the edge location before being returned to the user.
Subsequent requests from nearby users are served directly from the edge cache.
AWS CloudFront Example
On AWS, the most commonly used CDN service is Amazon CloudFront.CloudFront sits in front of applications and distributes content through hundreds of edge locations worldwide.
The origin can be an Amazon S3 bucket, an Application Load Balancer (ALB), an EC2 instance, or any HTTP server.
Static Content Caching
Static content changes infrequently, making it ideal for CDN caching.Examples include:
- Images
- CSS files
- JavaScript bundles
- Fonts
- Videos
- PDF documents
A request for the company logo may look like:
GET /images/logo.png API Response Caching
Although CDNs are commonly associated with static files, they can also cache HTTP API responses.Suppose a Spring Boot microservice exposes a product catalog.
GET /api/products Cache-Control: public, max-age=300 Subsequent requests during this period are served directly from CloudFront without invoking the Spring Boot service.
Cache-Control Headers
HTTP caching behavior is primarily controlled using response headers.The most commonly used header is Cache-Control.
Cache-Control: public, max-age=3600 Sensitive responses should disable caching.
Cache-Control: no-store | Directive | Description |
|---|---|
| public | Allows browsers and CDNs to cache the response. |
| private | Allows only the user's browser to cache the response. |
| max-age | Specifies how long the response remains fresh. |
| no-cache | Requires revalidation before using the cached response. |
| no-store | Prevents caching entirely. |
Setting Cache Headers in Spring Boot
Spring Boot allows cache headers to be configured directly in controllers.@GetMapping("/products")
public ResponseEntity<List<Product>> getProducts() {
return ResponseEntity.ok()
.cacheControl(CacheControl.maxAge(5, TimeUnit.MINUTES)
.cachePublic())
.body(productService.findAll());
}
When Should APIs Be Cached?
Not every API should be cached. Endpoints returning frequently changing or user-specific data generally should bypass the CDN.For example, the following endpoint should usually not be cached.
GET /api/orders GET /api/categories Cache Invalidation
Eventually, cached content becomes outdated.Suppose an administrator updates a product price. Users should not continue receiving the old response from edge locations.
There are several approaches to solving this problem.
The simplest approach is to use a short Time To Live (TTL), allowing cached responses to expire automatically after a few minutes.
Another common approach is cache invalidation, where the CDN is instructed to remove specific cached objects immediately after updates.
Many teams also use versioned URLs, ensuring that updated resources automatically receive new URLs.
/css/app-v2.css
/images/logo-v3.png Advantages
1. A CDN significantly reduces response times by serving content from edge locations close to users instead of routing every request to the origin server.2. Because many requests never reach the backend, the load on Spring Boot microservices and databases is greatly reduced.
3. This improves scalability, lowers infrastructure costs, and allows applications to handle sudden traffic spikes more effectively.
4. Modern CDNs also provide additional capabilities such as DDoS protection, TLS termination, HTTP/2 and HTTP/3 support, compression, and integration with Web Application Firewalls (WAF).
DDoS protection is a security service that keeps websites and online networks safe by blocking fake traffic and letting real users through.
Limitations
1. Edge caching is most effective for content that changes infrequently. Frequently updated or personalized data often results in low cache hit rates and provides little benefit.2. Improper cache configuration can also lead to stale content being served after updates.
3. Applications must therefore carefully choose appropriate Cache-Control headers, TTL values, and cache invalidation strategies.
Summary
A CDN improves application performance by serving content from geographically distributed edge locations instead of always contacting the origin server.In cloud environments such as AWS, Amazon CloudFront is commonly used with Spring Boot microservices to cache both static assets and cacheable API responses.
Proper use of Cache-Control headers, TTL, and cache invalidation ensures that users receive fresh content while significantly reducing backend load and improving global response times.
