Principles of Product Management: How the Internet Works (HTTP/S, DNS, APIs – REST/GraphQL, CDN)

How the Internet Works (HTTP/S, DNS, APIs – REST/GraphQL, CDN)

How the Internet Works (HTTP/S, DNS, APIs – REST/GraphQL, CDN)

What This Is

The internet is the invisible plumbing behind every digital product—from a fintech app fetching real-time stock prices to an e-commerce checkout processing payments. Understanding how data moves (HTTP/S), how users find your product (DNS), how your frontend talks to your backend (APIs), and how you deliver content globally (CDN) helps you: - Debug performance issues (e.g., why a checkout page loads slowly in Europe but not the U.S.).
- Design scalable features (e.g., building a real-time chat feature with WebSockets vs. REST).
- Prioritize technical debt (e.g., migrating from REST to GraphQL to reduce over-fetching in a mobile app).
- Collaborate with engineers (e.g., explaining to stakeholders why a DNS change takes 48 hours to propagate).

Real-world example: When Stripe launched its "Payment Links" feature (a no-code way to accept payments), the team had to optimize DNS routing to ensure low latency globally, use REST APIs for payment processing, and leverage a CDN to serve static assets (like the payment form) quickly. Without this, users in Asia might see a 5-second delay—enough to kill conversions.

Key Terms & Frameworks

• HTTP (Hypertext Transfer Protocol): The "language" browsers and servers use to communicate. Think of it like a waiter taking orders (requests) and bringing food (responses). HTTP/1.1 is the older version (slower, one request at a time); HTTP/2 is faster (multiple requests at once).
• HTTPS (HTTP Secure): HTTP + encryption (TLS/SSL). Without it, data like passwords or credit cards can be intercepted. ⚠️ Google ranks HTTPS sites higher.
• DNS (Domain Name System): The "phonebook" of the internet. Translates human-readable names (e.g., google.com) into machine-readable IP addresses (e.g., 172.217.3.110). Works via a hierarchy: Root DNS → TLD (Top-Level Domain, e.g., .com) → Authoritative DNS (e.g., Google’s servers).
• API (Application Programming Interface): A contract between systems. Your app’s frontend uses APIs to ask the backend for data (e.g., "Show me the user’s order history").
• REST (Representational State Transfer): A popular API style using HTTP methods (GET, POST, PUT, DELETE). Stateless (each request is independent) and resource-based (e.g., /users/123).
• GraphQL: A query language for APIs. Lets clients request only the data they need (e.g., { user(id: 123) { name, email } }). Avoids over-fetching (getting too much data) or under-fetching (needing multiple requests).
• CDN (Content Delivery Network): A network of servers that cache and deliver content (images, videos, JS files) from locations close to users. Reduces latency (e.g., a user in Tokyo loads assets from a Tokyo server, not a U.S. one).
• Latency vs. Bandwidth:
• Latency: Time for data to travel (e.g., 100ms from NYC to London). Measured in milliseconds (ms).
• Bandwidth: Amount of data transferred per second (e.g., 100 Mbps). Measured in megabits/second (Mbps).
• Formula: Total Load Time = Latency + (Data Size / Bandwidth)
• TCP/IP: The "postal service" of the internet. TCP ensures data arrives intact (like registered mail); IP handles addressing (like a street address).
• WebSockets: A protocol for real-time, two-way communication (e.g., chat apps, live sports scores). Unlike REST (request-response), WebSockets keep a persistent connection open.
• CORS (Cross-Origin Resource Sharing): A security feature that restricts how web pages can request resources from other domains. If your frontend (app.com) tries to fetch data from api.com, the server must include Access-Control-Allow-Origin: app.com in its response.
• Idempotency: A property of API operations where repeating the same request has the same effect as making it once (e.g., PUT /users/123 updates a user, but calling it twice doesn’t create two users). Critical for retries after failures.

Step-by-Step / Process Flow

How to Apply This Knowledge in a Product Scenario

Scenario: Your team is building a social media app with a "Stories" feature (like Instagram). Users complain that Stories load slowly in Brazil.

1. Diagnose the problem:
2. Use Chrome DevTools (Network tab) to check:
   • Latency: Is the initial request slow? (Likely a DNS or server location issue.)
   • Data size: Are images/videos too large? (Bandwidth issue.)
   • API calls: Are you over-fetching data? (e.g., fetching 100 stories when the user only sees 5.)

3. Example: You find that the GET /stories API call takes 1.2s in Brazil vs. 200ms in the U.S.

4. Map the data flow:

5. Draw a diagram of how a Story loads:
   User (Brazil) → DNS Lookup → CDN (for images) → API (for story data) → Database

6. Identify bottlenecks:

   
   
   • Is the API server in the U.S.? (High latency.)
   • Are images not cached in Brazil? (CDN miss.)
   • Is the API returning 10MB of data? (Over-fetching.)

7. Prioritize fixes:

8. Short-term (1–2 weeks):
   • Add a CDN (e.g., Cloudflare, AWS CloudFront) to cache images/videos in Brazil.
   • Optimize images (compress, use WebP format).
   • Implement GraphQL to let the frontend request only the first 5 stories (avoid over-fetching).

9. Long-term (1–3 months):

   
   
   • Deploy API servers in South America (e.g., AWS São Paulo region).
   • Use HTTP/2 to reduce latency for multiple requests.
   • Add prefetching (load stories in the background while the user scrolls).

10. Measure impact:

11. Track latency metrics (e.g., P99 latency for GET /stories in Brazil).
12. Monitor conversion (e.g., % of users who view a Story after opening the app).

13. A/B test: Compare load times before/after CDN implementation.

14. Communicate with stakeholders:

15. Explain trade-offs:
    • "Adding a CDN will cost $500/month but reduce load time by 60%."
    • "Migrating to GraphQL will take 2 sprints but improve mobile performance."
16. Use ICE scoring to prioritize:
    • Impact: High (faster load times → higher retention).
    • Confidence: Medium (CDNs are proven to work).
    • Ease: Medium (engineering effort to set up).

Common Mistakes

1. Mistake: Assuming all APIs are the same (e.g., treating GraphQL like REST).

2. Correction: GraphQL lets clients request exactly what they need, while REST returns fixed data structures. Use GraphQL for complex frontends (e.g., dashboards with many filters) and REST for simple CRUD apps.

3. Mistake: Ignoring DNS propagation time when launching a new domain.

4. Correction: DNS changes can take up to 48 hours to propagate globally. Plan launches accordingly (e.g., don’t announce a new feature at 9 AM if DNS updates at 8 AM).

5. Mistake: Not using a CDN for static assets (e.g., images, JS files).

6. Correction: CDNs reduce latency by 50–90% for global users. Always use one for static content. ⚠️ Don’t use a CDN for dynamic API responses (e.g., POST /payments).

7. Mistake: Overlooking HTTPS for "non-sensitive" pages (e.g., marketing sites).

8. Correction: Google ranks HTTPS sites higher, and browsers show "Not Secure" warnings for HTTP. Always use HTTPS.

9. Mistake: Not designing APIs for idempotency (e.g., allowing duplicate payments).

10. Correction: Use idempotency keys for critical operations (e.g., POST /payments). Example: Stripe’s API requires an Idempotency-Key header to prevent duplicate charges.

PM Interview / Practical Insights

1. Tricky question: "How would you reduce API latency for users in Australia if your servers are in the U.S.?"
2. Answer: Use a CDN for static assets, deploy API servers in Australia (e.g., AWS Sydney), and implement GraphQL to reduce over-fetching. For dynamic data, use edge computing (e.g., Cloudflare Workers) to run logic closer to users.

3. Why it matters: Interviewers test if you understand trade-offs between cost, speed, and engineering effort.

4. Distinction: REST vs. GraphQL

5. REST: Good for simple, cacheable APIs (e.g., GET /users). Over-fetches data (e.g., returns name, email, and address when you only need name).

6. GraphQL: Good for complex frontends (e.g., dashboards with many filters). Lets clients request only what they need (e.g., { user { name } }). Harder to cache.

7. Stakeholder trap: "Why can’t we just cache everything in the CDN?"

8. Answer: CDNs are great for static content (images, JS, CSS) but not for dynamic data (e.g., GET /user-profile). Caching dynamic data can lead to stale responses (e.g., showing an old profile picture). Use TTL (Time-to-Live) headers to control cache duration.

9. Debugging scenario: "Users in India report that your app crashes on launch. How do you debug?"

10. Answer:
    1. Check network logs (e.g., Chrome DevTools) for failed API calls.
    2. Verify DNS resolution (e.g., dig yourdomain.com in India).
    3. Test latency (e.g., ping your-api.com from India).
    4. Look for CORS errors (e.g., frontend can’t access API due to missing headers).
    5. Check CDN cache hits (e.g., are assets loading from a local server?).

Quick Check Questions

1. Your team wants to add a real-time chat feature to your app. Should you use REST or WebSockets?

2. Answer: WebSockets. REST is request-response (slow for chat), while WebSockets keep a persistent connection for real-time updates.

3. A user in Japan reports that your website loads slowly. The Network tab shows a 1.5s delay for the initial HTML request. What’s the likely cause?

4. Answer: High latency due to the server being far from Japan. Fix: Deploy servers in Asia or use a CDN for the HTML (if static).

5. Your frontend team complains that the GET /orders API returns 10MB of data, but they only need 5 fields. Should you switch to REST or GraphQL?

6. Answer: GraphQL. It lets the frontend request only the fields it needs, reducing over-fetching.

Last-Minute Cram Sheet

1. HTTP vs. HTTPS: HTTP = unencrypted; HTTPS = encrypted (TLS/SSL). Always use HTTPS.
2. DNS hierarchy: Root → TLD (.com) → Authoritative DNS (e.g., Google’s servers).
3. REST vs. GraphQL:
4. REST: Fixed responses, over-fetches data.
5. GraphQL: Custom queries, avoids over-fetching.
6. CDN: Caches static assets (images, JS) in global locations. ⚠️ Not for dynamic API responses.
7. Latency vs. Bandwidth: Latency = time to first byte; Bandwidth = data per second.
8. WebSockets: Real-time, two-way communication (e.g., chat, live updates).
9. CORS: Security feature; servers must allow requests from other domains.
10. Idempotency: Repeating a request has the same effect as making it once (e.g., PUT).
11. HTTP/2: Faster than HTTP/1.1 (multiple requests at once).
12. ⚠️ DNS propagation: Takes up to 48 hours. Plan launches accordingly.