DEV Community

Cover image for Part 4: Storage, Speed, and Global Reach
Juhi Srivastava
Juhi Srivastava

Posted on Originally published at Medium

Part 4: Storage, Speed, and Global Reach

Building a Web App: A Beginner's Guide to Cloud Architecture (Part 4 of 5)

Let's recap the journey so far.

In Part 1, we made sure our app wouldn't crash if a server suddenly died (High Availability). In Part 2, we survived a massive 50,000-user traffic spike by teaching the app to automatically clone itself (Scalability). In Part 3, we built a digital fortress around the network to keep hackers out (Security).

Our application is now an absolute tank. It is virtually unbreakable. But if we launch it right now, we are going to run into a completely different problem: It feels sluggish.

Imagine that 50,000-user traffic spike hits again. Your servers scale up perfectly, and the app stays online. But every single time a user loads the homepage, your web servers are forced to process a heavy 5MB hero image, and your database has to recalculate the exact same "Top 10 Events" list. Doing that exact same math 50,000 times a minute is exhausting and incredibly expensive.

To make matters worse, if your data center is in Virginia, a user trying to register from Tokyo is going to be staring at a blank screen for three seconds while the data physically travels across the Pacific Ocean.

A secure and scalable app isn't necessarily a fast app.
In Part 4, we are going to fix that. We will optimize our architecture by decoupling our storage, giving our database a short-term memory, and making the app load instantly for users anywhere in the world.

1. The Ephemeral Storage Problem (S3 & Blob Storage)
In an auto-scaling environment, your web servers are "ephemeral." This means they are temporary. The cloud provider creates and destroys them dynamically based on traffic.

Because of this, you can never treat a web server's hard drive as permanent storage. If a user uploads a profile picture and saves it directly to Web Server A, that picture will be permanently deleted the moment the traffic spike ends and the auto-scaler terminates Web Server A.

To fix this, we must make our web servers stateless. Compute and storage need to be completely separated.
Instead of saving files locally, the web server takes the user's uploaded file and pushes it to a centralized, infinitely scalable object storage bucket.

  • AWS calls this Amazon S3 (Simple Storage Service).
  • Azure calls this Azure Blob Storage.

Now, it doesn't matter if you have two web servers or two hundred; they all read and write to the exact same centralized storage bucket.

2. The Speed of Light Problem (Content Delivery Networks)
Moving our images and videos to Amazon S3 solves our storage problem, but it introduces a latency problem.

Data travels fast, but it cannot break the speed of light. If your S3 bucket is located in a data center in Virginia, a user in Tokyo is going to experience a delay while that image travels across the Pacific Ocean.

We solve this using a Content Delivery Network (CDN).
A CDN is a massive global network of proxy servers located in hundreds of cities around the world (called Edge Locations). When you put a CDN in front of your storage bucket, it caches copies of your static files at these edge locations.

When the user in Tokyo requests the profile picture, the request doesn't go all the way to Virginia. It goes to a CDN edge node in Tokyo, which serves the image in milliseconds.

  • AWS calls its CDN Amazon CloudFront.
  • Azure calls its CDN Azure Front Door.

3. The Database Bottleneck (In-Memory Caching)
Static files (images, CSS, PDFs) are handled by the CDN, but what about dynamic data?

Reading from a relational database is a computationally expensive task because the database has to read from disk. If 10,000 users visit your homepage, and the homepage displays the "Top 10 Newest Articles," your web servers are going to ask the database for the exact same information 10,000 times. This is a massive waste of resources.

We fix this by introducing a caching layer right in front of the database. Think of the cache as the database's short-term memory. It stores data in RAM, making it blisteringly fast to retrieve.
When a user requests the homepage, the web server asks the cache first:

  • Cache Hit: If the "Top 10 Articles" are in the cache, the cache returns them instantly. The database does no work.
  • Cache Miss: If the data isn't there, the web server queries the database, returns the articles to the user, and writes the result into the cache for the next user

The industry standard technology for this is Redis.

  • AWS manages this for you with Amazon ElastiCache for Redis
  • Azure provides Azure Cache for Redis.

Architecture Diagram

Azure Architecture Diagram

Azure Architecture Diagram

AWS Architecture Diagram

AWS Architecture Diagram

Further Reading & Official Documentation

If you want to dive deeper into the concepts covered in this article, check out the official documentation from AWS and Microsoft:

References & Further Reading

AWS Storage & Caching

Azure Storage & Caching

Coming Up Next in Part 5: The Unsung Hero of the Cloud (Decoupling)
Our architecture is almost complete. We have solved for availability, scaling, security, and speed. But there is one final, critical piece of enterprise architecture left.
What happens when a user triggers a massive background job, like uploading a 2GB video or initiating a script that sends 50,000 emails? If your web server tries to do this while the user waits, the app will freeze and the connection will time out.
In our final installment, Part 5, we will introduce Message Queues (AWS SQS / Azure Service Bus) and Asynchronous Processing. We will learn how to decouple our architecture so our web servers can hand off heavy tasks to a hidden fleet of background worker servers, keeping the user interface fast and responsive.

Stay Tuned!

Top comments (0)