Large-Scale Architecture — Series 2

Preview — 3 of 10 questions

Youre designing a group chat feature. Messages sent by different users can arrive at the server slightly out of the order they were actually composed, due to variable network latency. Whats the standard approach to guarantee consistent message ordering for every client viewing the conversation?

ARely on each client's local system clock timestamp to sort messages — device clocks are always perfectly synchronized, so this is sufficient

BOrdering doesn't really matter for chat applications — users don't notice message order

CAssign each message a monotonically increasing sequence number (or a logical/vector clock) at the server, scoped to the conversation, at the moment it's received and persisted — clients then order messages by that server-assigned sequence, never by client-reported timestamps

DUse "exactly-once" delivery guarantees from the message queue, which automatically preserves send order regardless of network conditions

A CDN caches your sites static assets at edge locations worldwide. You deploy a new version of `app.css`, but users keep seeing the old, cached version for up to 24 hours. Whats the standard fix?

AReduce the CDN's TTL to 0 seconds for every asset, so nothing is ever cached — this is the standard production approach

BManually contact the CDN provider's support team to clear the cache after every single deploy

CCDNs are fundamentally unable to cache CSS/JS files — only images and video can be cached

DUse content-hashed, versioned filenames (e.g., app.a1b2c3.css) so every new build produces a brand-new URL — the old cached version simply becomes unreferenced and irrelevant, while the new URL is always a guaranteed cache miss on first request, requiring no explicit invalidation at all

Compare round-robin, least-connections, and consistent hashing as load balancing strategies. Which statement is accurate?

ARound-robin distributes requests in a fixed rotation regardless of each server's current load — simple, but it can overload a server still busy processing a slow request from an earlier round; least-connections instead routes to whichever backend currently has the fewest active connections, adapting to real-time load; consistent hashing routes based on a hash of the request (e.g., a user ID), so the same client consistently reaches the same backend — valuable for session affinity or cache locality, at some cost to perfectly even load distribution

BAll three algorithms produce identical request distribution in practice — the choice between them is purely stylistic

CConsistent hashing is only ever used for DNS-level load balancing, never for application-level request routing

DLeast-connections is strictly worse than round-robin in every scenario, because it requires tracking extra per-server state

Answer all 10 questions (7 more), see explanations for every answer, and track your score.