What is Sysiq and how is it different from reading static blogs?

Sysiq is an interactive system design platform where you don't just read about distributed systems — you actively build and test them. Solve real-world engineering challenges using a live diagram canvas, guided architectural labs, and real-time napkin math estimation tools.

Is Sysiq suitable for preparing for FAANG system design interviews?

Yes. Sysiq is tailored specifically for mid-level, senior, and staff engineering interviews (L4–L7). The problem bank covers actual interview scenarios: URL shorteners, distributed rate limiters, key-value stores, video streaming architectures, and real-time chat systems.

Can I use Sysiq for free?

Yes. Foundational modules, introductory interview problems, the Napkin Math calculator, and the global engineering leaderboard are all free with no time limit.

Do I need prior distributed systems experience to get started?

Not at all. The curriculum starts with fundamental building blocks — DNS, reverse proxies, database replication, and caching — and progressively walks you up to complex architectures like Raft consensus, vector clocks, and LSM-tree compaction.

All Modules/Networking & DNS

TLS, HTTP & Connection Pooling

TLS handshake, HTTP/1.1 vs HTTP/2 vs HTTP/3, keep-alive, and connection pooling

12 min read

QUIC saved two round trips. Who encrypts the bytes?

Last topic cut ceremony to 1 RTT for new QUIC visits and 0-RTT for returning ones, with loss isolated per stream and roaming on one connection ID. But most backend traffic still rides TCP with its 1-RTT SYN plus 1 to 2 RTT of TLS, and every byte on either transport travels readable without encryption. TCP hands you raw, reliable bytes and that is all. Nobody verified who sent them, nobody encrypted them, and every fresh connection pays the full handshake toll again. TLS, meaning Transport Layer Security, the encryption layer that authenticates the server and scrambles bytes, HTTP, meaning the request-response protocol that frames those bytes, and connection pooling, meaning reusing warm connections instead of rebuilding them, each erase one of those pains, in that order.

TCP handshake  →  TLS handshake  →  HTTP request/response  →  keep-alive reuse
  1 RTT             1-2 RTT              1 RTT per exchange      0 RTT (reuse)
  ─────────────────────────────────────────────────────────────────────
  Without pooling:  3-4 RTT before first byte
  With TLS 1.3 + keep-alive + HTTP/2: 1 RTT, then 0 for next requests

RTT means one round trip, there and back. On an 80ms path, 3–4 RTT is 240–320ms of ceremony before the app byte moves. The rejected per-request connection pays it every time.

Why does the first byte take so long?

TLS 1.2, with 2 RTT

Client                        Server
  ClientHello  ──────────────►
               ◄──────────────  ServerHello
                                Certificate
                                ServerKeyExchange
                                ServerHelloDone
  ClientKeyExchange
  ChangeCipherSpec
  Finished      ──────────────►
               ◄──────────────  ChangeCipherSpec
                                Finished
  [Application Data]

The certificate, meaning the server's signed identity document, plus two full exchanges cost 2 round trips before app data. Every cold connection pays it.

TLS 1.3, with 1 RTT (+ 0-RTT)

Client                        Server
  ClientHello
   + key_share
   + early_data* ─────────────►
               ◄──────────────  ServerHello
                                + key_share
                                {EncryptedExtensions}
                                {Certificate}
                                {Finished}
  {Finished}    ──────────────►
  [Application Data]
  * 0-RTT replays if enabled, idempotent GET only

TLS 1.3 guesses the key share up front, cutting crypto to 1 round trip. 0-RTT, meaning data on the very first packet for returning clients, saves one more, but replays are possible, so it fits only safe repeated reads.

0-RTT saves a round trip but its first packet can be replayed by an attacker capturing and resending it. Enable it only for safe, idempotent reads, meaning requests harmless to run twice, and require anti-replay defenses at the edge before trusting it for anything else.

HTTP keeps reinventing the envelope

Version	Wire model	Head-of-line blocking	Use when
HTTP/1.1	Text, 1 request per TCP connection (pipelining broken)	TCP blocking; 6 connections per origin in browsers	Simple backends, curl, webhooks
HTTP/2	Binary frames, streams multiplexed on 1 TCP	Still TCP blocking, so one lost packet stalls all streams	Browser pages, gRPC (HTTP/2 transport)
HTTP/3	QUIC (UDP), streams over independent QUIC streams	No TCP blocking; loss on stream N does not block stream M	Lossy mobile, edge, QUIC-aware balancer

Why HTTP/2 multiplexing matters

Multiplexing means interleaving many streams on one connection. Without it, loading 50 assets needs 8 or more TCP connections, each needing TLS. With it, one connection carries 50 interleaved streams, amortizing one handshake across all of them.

Why QUIC matters

Head-of-line blocking means one lost packet freezes everything behind it. On LTE with 2% loss, HTTP/2 throughput collapses from that freeze. QUIC keeps independent streams flowing, cutting p95 page load, where p95 means the slowest 5% threshold, by 15–30%.

Negotiation

ALPN, meaning a TLS extension where client and server agree on the app protocol inside the handshake, negotiates h2 vs http/1.1. Alt-Svc, meaning an HTTP header advertising alternatives, advertises h3.

Stop paying the handshake toll twice

The rejected client opens a new TCP plus TLS connection per request, burning 3–4 round trips and a file descriptor, meaning an OS handle per socket, every time, then throws it all away. At 80ms RTT that is 240–320ms per request, so 100 requests a second each pay the toll separately. Pools keep warm connections around and lend them out. Every serious client library already ships one: Go's http.Transport, meaning Go's connection manager, Node's Agent.keepAlive, Java's HttpClient, Python's urllib3.PoolManager. Your job is turning it on and sizing it sanely.

Keep-Alive & pooling knobs

keepAlive: true + maxSockets: 50 per origin, meaning per host-plus-port you call.
Idle timeout (60–120s). Close before balancer idle timeout (usually 60s) to avoid RST, meaning an abrupt reset that errors the next reuse.
Max lifetime (5–10 min). Rotation for DNS changes and cert rotation.
Health check: pool should evict broken sockets instead of handing them out again.

const agent = new https.Agent({
  keepAlive: true,
  maxSockets: 50,
  maxFreeSockets: 10,
  timeout: 30000,
  keepAliveMsecs: 1000
});

What you gain

TLS handshakes / sec10x fewer

p50 latency to same host-30–60ms

TIME_WAIT sockets-80%

LB connection churnstable

TIME_WAIT is the cooldown state closed TCP sockets linger in. Fewer fresh connections means fewer of them. Pool per origin, not per path, and pool per process, because 100 workers each with 50 sockets is 5,000 sockets aimed at one upstream.

What a cold connection really costs in milliseconds

The handshake toll is not abstract. On a 80ms cross-region path, TCP (1 RTT) plus TLS 1.2 (2 RTT) burns about 240ms, which is 3 times 80, before the request even leaves, on every cold connection, every redirect, every new origin. TLS 1.3 cuts the crypto half to 1 RTT, so about 160ms total, and a warm pooled connection cuts all of it to zero plus the 1 RTT the request itself needs. Multiply by six fresh connections per page and the unpooled page pays over a second of pure ceremony: 6 times 240ms is 1.44 seconds of handshakes before content.

Setup	Cost at 80 ms RTT	Notes
Cold TCP + TLS 1.2	~240 ms	Full cert chain (~3–5 KB) on every handshake
Cold TCP + TLS 1.3	~160 ms	Session resumption cuts repeats to ~80 ms
Warm pooled + HTTP/2	~0 ms + 1 RTT per exchange	Multiplexed streams share the one handshake

Certificate hygiene matters too: ECDSA certificates, meaning elliptic-curve signatures that verify faster in fewer bytes, beat RSA-2048 on both CPU and wire size, and OCSP stapling, meaning the server attaches its own revocation proof so the client skips a separate lookup, saves a hidden round trip on first visit that otherwise hits an outside responder.

How pooling poisons you at 3am

Pools fail in the opposite direction from handshakes: not too slow, but too sticky. A pool that never evicts holds connections to backends that already drained, so deploys look finished while a slice of traffic keeps hitting the old pods. A pool sized at 50 sockets per process across 100 workers opens 5,000 sockets at one upstream (50 times 100), which reads the surge as an attack and starts resetting. And a pool keyed per process never learns DNS changed, pinning traffic to a dead IP long after failover. What breaks first is the deploy: errors cluster right after releases while origin health looks fine, the signature of stale pooled sockets.

The knobs that keep pools honest

Idle timeout below the balancer's: if the balancer kills idle at 60 s, close pooled sockets at 45–50 s. The alternative is a race where the balancer resets a socket just as you reuse it.
Max lifetime of 5–10 minutes: forces periodic DNS re-resolution and cert rotation pickup. Without it, blue-green cuts, meaning shifting traffic between old and new fleets, leave pooled traffic on the old fleet.
Per-origin caps with queueing: maxSockets around 25–50 per origin per process, with a bounded wait queue, then autoscale the process count, not the socket count.
Retry only what is safe: retry idempotent GETs, meaning reads safe to repeat, on a fresh socket once. Never blindly retry POSTs. A stale pooled socket plus an unsafe retry turns one glitch into two charges.

If errors cluster right after deploys or DNS moves while origin health looks fine, suspect the pool before the app. A client with no max-lifetime or eviction is not a cache. It is a time capsule holding yesterday's topology.

What to carry into edge caching

1TLS 1.3 costs one round trip; 1.2 costs two. Upgrade, and save 0-RTT for repeat safe requests only. Bigger pools are not better past the upstream's comfortable concurrency, so size per origin and scale processes instead.
2HTTP/2 shares one connection but still stalls on TCP loss; HTTP/3 over QUIC finally removes that stall per stream.
3Reuse connections or bleed latency: pool per origin, expire idle sockets before the balancer does, and retry only idempotent reads.

Pipes are fast and private now: warm pooled connections cost 0 ms plus 1 RTT, and six cold ones no longer burn 1.44 seconds of ceremony. But every exchange still pays the distance floor, with 80 ms a region away and 150 ms across an ocean. What if the bytes never had to cross the ocean at all?

TCP, UDP & QUIC

Content Delivery Networks

Next: Lab

Try an interactive lab

See the concept running

Then: Quiz

Test retention

Quick recall