Networking, APIs and CDNs

The journey of a request

Before your code runs, a lot happens. When a browser loads https://shop.example.com:

100%

Figure SDA-FND-09-1 · Request journey: DNS, CDN, origin · © forcsguy.com

1. DNS turns the name into an IP address. Answers are cached at several levels for a time given by the record's TTL, so changes spread gradually.
2. A connection is opened (TCP) and secured (TLS). Each step costs round trips, so long distances hurt.
3. HTTP carries the request and response.

Latency is mostly physics: a round trip across an ocean costs over 100 ms no matter how fast your code is. The only fixes are fewer round trips and moving data closer to the user.

Image: Syced · CC0 · Source · Wikimedia Commons: Fujikura optic fiber at Science Museum

Name lookup is a short chain of questions, each answered by a more specific server:

100%

Figure SDA-FND-09-2 · How a name becomes an address · © forcsguy.com

Image: Howe's Adventures & Achievements of Americans · Public domain · Source · Wikimedia Commons: Transatlantic submarine cable map

CDNs

A content delivery network is a worldwide set of servers (edges) that keep copies of your content close to users.

• Great for static files: images, video, scripts, stylesheets, and often whole pages that rarely change.
• Cuts latency, absorbs traffic spikes and shields your origin from load.
• Controlled by cache headers (Cache-Control: max-age=...) and purge APIs when content changes.
• Use a versioned file name (app.3f9a.js) so you can cache for a year and still ship updates instantly.

100%

Figure SDA-FND-09-3 · Content delivery in tiers · © forcsguy.com

Choosing an API style

Style	Strength	Watch out for
REST over HTTP/JSON	Simple, cacheable, universal	Over-fetching, many round trips for complex screens
GraphQL	Client asks for exactly the fields it needs	Query cost control, caching is harder
gRPC	Fast binary protocol, strong contracts	Needs tooling, awkward in browsers
SOAP	XML messages with a formal contract (WSDL) and built-in standards for security and transactions, still common in banks and older enterprise systems	Verbose, heavier tooling, rarely chosen for new public APIs
WebSockets / SSE	Server can push live updates	Long-lived connections need extra capacity and care

A good default is REST for public APIs, gRPC between internal services if you need speed, and WebSockets only where live push is truly needed.

Designing good APIs

• Version them so old clients keep working.
• Paginate list endpoints (cursor-based pagination stays stable as data changes).
• Make writes idempotent with idempotency keys, so a retry does not double-charge.
• Return clear errors with correct status codes.
• Authenticate and rate limit at the edge, often in an API gateway that also handles routing, logging and TLS.

100%

Figure SDA-FND-09-4 · API gateway in front of services · © forcsguy.com

More on this site