Evaluation

In one line: the compliance tables here are more mechanism-specific than most in the module. Two rows are genuinely strong; two describe the build phase and quietly leave the deployment phase uncovered.

Functional requirements

Configuration is listed as satisfied and the hard half is missing

The requirement was "users must be able to manage environment-specific configurations, such as database connections and API endpoints." The mechanism given is a config service that holds global and regional state, which satisfies the literal reading.

What it does not address is the coupling Lesson 3 raised: configuration changes are deployments too, and they need the same machinery.

Code rollback WITHOUT config rollback:
  binary reverts to v1.0
  config still holds v1.1's new database endpoint
  -> v1.0 code, v1.1 config: a combination NOBODY ever tested

Configuration changes are also, empirically, a leading cause of production incidents — and they are riskier than code changes precisely because they usually skip the pipeline: no build, no tests, no staging, often no review, and they take effect in seconds.

The fix is to treat config as an artifact: version it, tie the version to the build version, roll them back together. The design's global state service already holds {build_version: build:1.1}; extending that to {build_version, config_version} is a small change with a large payoff.

A rollback that reverts one of two coupled things is not a rollback.

Non-functional requirements

The availability row describes build availability and calls it system availability

Availability: "The configuration service enables automated failover by rerouting build requests to backups. Redundancy is ensured with duplicated servers, databases, and load balancers."

Both sentences are about the build side. Reroute build requests; duplicate servers and databases.

Ask instead what availability means for the deployment side, and the row is silent:

What if the GLOBAL STATE SERVICE is unavailable?
  -> no deployments can be triggered, AND no rollbacks
     (it is the single strongly-consistent component; Lesson 7)

What if a REGIONAL CONFIG SERVICE is unavailable?
  -> that region silently stops receiving deployments
     (it polls; nothing alerts on a poller that stopped)

What if a REGIONAL BLOB STORE is unavailable?
  -> that region's machines cannot fetch binaries mid-rollout
     -> a PARTIALLY deployed region, versions split across the fleet

The third is the dangerous one and it is unaddressed. The design's own quiz answer for availability is "redundancy through duplicated elements," which is right for stateless components and does not cover a partially-completed global rollout.

A deployment system's worst availability failure is not being unable to deploy — it is being unable to finish, leaving the fleet split across versions with no mechanism to converge. The declarative model from Lesson 7 actually helps here: machines keep polling and converge when the store returns. Saying that is the right answer, and the design does not.

The fault tolerance row is the best in the chapter, and it earns it by naming a mechanism

Fault tolerance: "Workers regularly send heartbeats through the pub-sub system, recorded in an SQL database; if one is missed, the task is reassigned to an available worker."

This is what a compliance row should look like. It names a specific mechanism, ties it to a specific failure, and the mechanism actually delivers the requirement — "every build must definitively report success or failure."

Compare with rows elsewhere in the module that say "replication ensures fault tolerance" without saying replication of what, against which failure.

Two qualifications, both from Lesson 4:

"If one is missed" is too aggressive. A single missed heartbeat should not trigger reassignment — a GC pause or a brief network blip will do that routinely. Real leases require several consecutive misses, and the interval is a trade between detection speed and false reassignment.

Reassignment without fencing allows duplicate execution. Both the original and the replacement worker can write to the same artifact path. The fix is a fencing token rejected on stale writes, or reproducible builds making the duplicate harmless — ideally both.

A mechanism-specific compliance row is falsifiable, which is what makes it worth writing.

Scalability is genuinely easy here, and it is worth knowing why

The scalability row is short and it is right, for a reason the design does not state: almost nothing in this system holds state that constrains scaling.

That last row is the whole scaling constraint, and it is fine because the object is one key per project and the read fan-in is absorbed by the regional tier.

Compare with the module's other systems, where scaling meant choosing a partition key and living with its skew — user IDs and celebrities, prefix ranges and letter frequency, hosts and domain concentration. Here there is no partition key to get wrong, because the work is independent and the shared state is tiny.

A system whose work is independent and whose shared state is one small key scales trivially — and recognizing when you are in that situation is as useful as knowing how to shard when you are not.

What the evaluation omits

Four things a strong answer adds, each covered earlier:

Retention. Rollback reads from blob storage and no policy says what is kept. A retention policy is a rollback policy (Lesson 8).

The aggregate bandwidth figure. The performance row credits P2P without ever stating the 1.07 Tbps that makes it mandatory (Lesson 6).

The missing gates. No staging, no test gate before production, no automatic rollback — three of the seven pipeline stages (Lesson 8).

Supply-chain integrity. No signing, no provenance, no verification at install, on the one system whose compromise implies compromise of everything else (Lesson 9).

Next: the interview walkthrough.