Day 3 : Bringing Your E-Commerce App to Life!

Hey there! In last blog we crafted very skeleton design of our app, today’s session is going to be even more exciting! So far, we’ve set up our server infrastructure and made our first major system design decisions. But what good is an app if people can’t access it?
Imagine someone typing ourcoolapp.com in their browser. What should happen?
✅ They should see our beautifully designed webpage.
✅ They should be able to register and log in.
✅ The app should respond to their actions smoothly.
But wait… how do we actually serve our web pages? 🤔
Let’s dive deep into where and how to store them!
🧐 Where Should We Store Our Web Pages? (CDN vs. AWS Server)
Our website consists of static files like HTML, CSS, and JavaScript that define how it looks and interacts. Now, we have two main options to store these files:
1️⃣ Host them on our AWS Server
2️⃣ Use a Content Delivery Network (CDN)
🛠️ Option 1: Serving Pages from Our Server
- Every time a user visits our site, their browser requests the webpage from our AWS server.
- Our server fetches the page and sends it back as a response.
- Works fine… but not the best approach for a scalable system.
⚡ Option 2: Using a Content Delivery Network (CDN)
A CDN is a globally distributed network of servers designed to deliver content faster.
Instead of storing web pages on a single AWS server, a CDN caches them across multiple locations.
🌎 How CDN Improves Performance
- If you’re in Mumbai, you get the page from an India-based server.
- If a user is in New York, they fetch the page from a New York-based server.
- This means faster load times and reduced latency no matter where your users are.
💰 CDN = Cheaper & Faster
Companies like Akamai, AWS CloudFront, and Cloudflare handle this globally distributed caching efficiently.
- CDNs reduce load on your main server (less compute power needed).
- Static assets (images, videos, etc.) load much faster.
📌 Final Decision: We go with a CDN (AWS CloudFront) to serve our website efficiently. Where we will be storing static assets and the remaining data will be stored in db.
🤨 But Why Not Store Everything on a CDN?
Great question! You might wonder:
“Why not just store everything — including user data — in the CDN?”
Here’s the issue: CDNs are designed for static content, not dynamic data.
🔄 Data Consistency Challenges in CDNs
Imagine a T-shirt product with 50 items in stock.
- A US-based user places 40 orders.
- An India-based user orders 11 more.
- Oops! We just oversold! (51 orders for 50 items)
Why? 🤔
CDN replicates data globally, but keeping inventory updates synchronized across multiple CDN servers is not reliable.
✅ Solution: Use a Database for Real-Time Data
1️⃣ CDN for Static Content → HTML, CSS, images, videos, product descriptions.
2️⃣ Database for Dynamic Content → Orders, inventory, user info.
💡 Key Takeaway: Use CDNs for speed, but store critical data in a database for accuracy! fetch dynamic data to check the realtime value of orders or dynamic data for solving consistency challenge.
🌍 How Do We Upload Files to a CDN?
With CDN servers spread globally, how do we upload and sync files efficiently?
For this we need to create some sort of file system for cdn to pull the latest data in definite interval. We can choose any existing filesystem out there like Hadoop or simple instance of AWS s3 bucket.
🛠️ Automated File Syncing with AWS S3
AWS S3 (Simple Storage Service) acts as our file system.
- When we add new files, S3 automatically syncs them with the CDN.
- Global distribution happens in real-time.
🗂️ How It Works
1️⃣ You create a public folder on S3.
2️⃣ Every few seconds, S3 checks for new files.
3️⃣ New files get synced across CDN servers worldwide.
💡 Why S3?
✅ Fully managed (no manual scaling required).
✅ Highly durable & consistent.
✅ Integrates seamlessly with AWS CloudFront.
📌 Final Decision: AWS S3 + CloudFront for fast, reliable web page delivery!
🌐 How the Internet Works: DNS & Domain Setup
Now that our pages are on a CDN, how do users actually reach our website?
When someone types ourcoolapp.com in their browser, what happens?
🌍 The DNS (Domain Name System) Process
1️⃣ The browser asks a Domain Name Server (DNS):
“Where is ourcoolapp.com hosted?”
2️⃣ The DNS looks up the corresponding IP address (e.g., 192.168.1.1
).
3️⃣ The browser caches this IP to speed up future visits.
4️⃣ The browser sends a request to the IP → the CDN delivers the page.
This is why we buy domains from providers like GoDaddy or AWS Route 53.
- We tell the DNS provider to map our domain to our CDN’s IP address.
📌 Final Decision: We register our domain & configure DNS to point to AWS CloudFront.

💾 What Database Should We Use?
Now that our users can register & log in, we need a database.
🤔 SQL vs NoSQL: What’s the Best Choice?
Many startups overthink this, spending days debating SQL vs. NoSQL.
💡 Reality: Just pick something you’re comfortable with!
💡 Best Choice for Startups? SQL!
1️⃣ Structured & reliable (great for user data, transactions).
2️⃣ Easy to query using SQL (industry standard).
3️⃣ Easier to hire for (SQL knowledge is widespread).
📌 Final Decision: AWS RDS (Relational Database Service) using PostgreSQL for structured, reliable storage.
🚀 Summary of Our Day 3 Decisions

✅ Web Pages Served via CDN → AWS CloudFront
✅ Static Files Stored in AWS S3 → Auto-syncs with CDN
✅ Dynamic Data Stored in SQL Database → AWS RDS (PostgreSQL)
✅ Domain Registered & Pointed to CDN → Using AWS Route 53 or GoDaddy
With all these pieces in place, our app is now publicly accessible, fast, and scalable! 🎉
See you in the next blog! 😃✨