Architecture Overview

Our infrastructure follows a modern distributed architecture pattern that prioritizes scalability, reliability, and performance. We know some developers don't like magic. So we've done our best to be transparent about how our underlying infrastructure is put together. If you have questions, feel free to reach out.

The Big Picture

Think of our infrastructure as a well-oiled assembly line (but for you application, not cars). Each component has a specific job, and they work together to deliver top performance for your application:

• CDN (Content Delivery Network): Global servers that cache your static assets, as well as pages and parts of your web application. The CDN is configured to listen to your webframeworks specific cache-control headers and other caching related quirks (like stale-while-revalidate).

• Kubernetes: All functions in your applications are containerized then managed and scaled by one of our many Kubernetes clusters. As request volume increases, our system automatically scales up your application behind one of our many load balancers. This ensures smooth handling of traffic spikes while maintaining consistent performance. The containerized nature of the deployment means your application runs in identical environments across all instances, eliminating environment-related issues. Each cluster consists of a minimum of 3 redundant control planes as well as multiple compute nodes that autoscale up in seconds when resource thresholds are met. This ensures there is always slack capacity for applications that have hard traffic spikes.

• Global Cache: Our system's short-term memory, storing frequently accessed data for ISR, PPR, and other framework based caching functionality. You framework leverages this cache to fulfill requests faster and improve page load speeds.

• Build Servers: Everytime you push to github and trigger a deployment your code changes are picked up by our build servers. These servers build, package, and ship your application code to the appropriate CDN, k8s cluster, and caching servers.

How It All Connects

Requests flow through our system like this:

Request 
    --> CDN (checks closest server first)
        --> CDN Cache Hit
            --> Response
        --> CDN Cache Miss
            --> K8s App/Function (app/func may call global cache) (multiple containers are load balanced)
                --> Response
                
GitHub Push
    --> Build Process (all in the CD Servers)
        --> Global Cache Creation
        --> CDN Upload & Configuration
        --> K8s Deployment

This setup ensures we maintain high availability while keeping response times snappy. Each component will get its own deep-dive page, but this overview should give you the 30,000-foot view of how everything fits together.

The actual component interactions are more complex than above. We plan to share those details in individual component pages in the near future. But if you have questions now, please let us know. We are happy to answer any questions you may have.