Detailed Design: Components

In one line: the manager node is the centre of this design and its single point of failure. Everything interesting about the blob store's operations, and its limits, runs through it.

The architecture

Component	Role
Client	A user or program that initiates API requests
Rate limiter	Restricts the number of requests based on user subscription or IP address to prevent exceeding usage limits
Load balancer	Distributes incoming traffic across servers. Can route to different regions, data centers, or servers based on user location — DNS load balancing is often used for geographic routing
Frontend servers	Forward write and delete requests to the appropriate storage servers
Data nodes	Store the actual blob data. Blobs are split into fixed-size pieces called chunks. A data node may store all chunks of a blob or a subset
Manager node	The central coordinator managing data nodes, storage paths, and access privileges. Access is private (owner only) or public (anyone)
Metadata storage	A distributed database holding account metadata (user info and containers), container metadata (blobs per container), and blob metadata (storage locations)
Monitoring service	Monitors health and disk usage of data nodes and the manager node. Alerts administrators to failures or low disk space
Administrator	Manages alerts and performs routine maintenance to ensure reliability

Note the split: the manager node handles metadata, data nodes handle bytes

Small control decisions and large payloads travel separately — the same split as a presigned URL, one layer down.

This is the defining structural decision, and it is the same one GFS and HDFS make.

The manager node answers "where does this blob live and may you touch it?" — small questions with small answers. Data nodes move megabytes. Keeping those on separate paths means the coordinator never touches bulk data, so its capacity is measured in operations, not bandwidth.

Lesson 4's 400x egress ratio is why this matters so much. If every byte flowed through the manager node, it would need to carry 463 Gb/s and the design would be dead on arrival. Instead the manager node handles a metadata lookup and the client reads chunks directly from data nodes (Lesson 7).

Same principle as the rate limiter being consulted rather than traversed, and the pub-sub broker being deliberately dumb: keep the coordinator off the data path and it stays cheap.

The manager node is a single point of failure — and the answer is checkpointing

"Can the manager node be considered a single point of failure? If so, how can we address this problem?"

Yes — it is the central point of a blob store and is a single point of failure. We need a backup or shadow server to replace it.

The technique is checkpointing: snapshots of the data at different time intervals. A snapshot captures the state, data, and hardware configuration of the running manager node, as well as messages in transit between the manager and data nodes. It maintains the operation log in an external storage area or snapshot repository. If the manager node fails, an automated system or the administrator uses the snapshot to restart it from the state it failed at and replays the operation log.

The snapshot plus operation log pairing is the important part, and it is exactly the write-ahead log pattern from the databases material. A snapshot alone loses everything since it was taken; a log alone takes forever to replay from the beginning. Together: restore the snapshot, replay only the log after it.

Notice also that the snapshot captures messages in transit. That is unusual and necessary — a chunk write the manager node had ordered but not yet recorded would otherwise be lost, leaving data nodes holding chunks nothing knows about.

Access control lives on the manager node, which is why reads must go through it

The manager node holds access privileges — private (owner only) or public (anyone).

That means a read cannot skip it. Lesson 7's read workflow has the manager node verify authorization before returning chunk locations, and only then does the client talk to data nodes directly.

Which raises the obvious question: once a client knows the chunk locations, what stops it reading them again later, or sharing them? In practice the answer is capability-bearing, time-limited tokens — the system-generated URL from Lesson 3, carrying an expiry. The data node validates the token rather than re-checking the ACL, so authorization stays centralized while enforcement is distributed.

DNS load balancing for geographic routing connects two earlier chapters

"DNS load balancing is often used for geographic routing" is a small clause that ties the DNS and Load Balancers chapters directly into this design.

At 463 Gb/s of egress, serving every user from one region is untenable — both for cost and for latency. DNS-level routing sends users to their nearest region, so a request from Europe never crosses the Atlantic.

The catch DNS flagged applies here too: DNS routing is coarse and slow to change, because resolvers cache. It is right for steady-state geographic distribution and wrong for fast failover, which is why it sits above the load balancer tier rather than replacing it.

Key takeaway

The manager node owns placement, paths, and access; data nodes own bytes; and the two are on separate paths so the coordinator never carries bulk traffic. That makes the manager node the system's single point of failure, handled by checkpointing — periodic snapshots plus an operation log, the write-ahead-log pattern applied to a coordinator.

Interview signal by level

Level	What a strong answer sounds like
L4	"A manager node keeps track of where blobs are and data nodes store them."
L5	Separates the paths: "metadata goes through the manager node, bulk data goes straight to data nodes — otherwise the coordinator would have to carry all the read bandwidth."
Staff+	Handles the SPOF properly: "the manager node is a genuine single point of failure, so I'd checkpoint it — periodic snapshots plus an operation log, restore the snapshot and replay from there. The snapshot has to include in-flight messages, or a chunk write it had ordered but not recorded leaves orphaned data. And since it also holds access control, reads must consult it — but I'd have it issue a time-limited token so data nodes enforce without re-checking ACLs."

Next: how the operations actually run.