Why architecture matters here
Spanner surprises come from mismatching workload to architecture. Cross-region strong reads pay TrueTime waits. Cross-directory transactions pay 2PC. Hot rows cause split hotspots. The architecture matters because schema + region choices shape SLO.
With the pieces mapped, you can pick region config, use interleaved tables to avoid cross-directory 2PC, and choose read variants that match consistency needs.
The architecture: every piece explained
The top strip is the physical stack. Client SQL arrives via gRPC. Zone / region hierarchy holds replicas. Paxos group replicates each split (a range of a table). Directories are logical placement units that migrate with load.
The middle row is the correctness machinery. TrueTime API returns TT.now() = [earliest, latest] with bounded uncertainty. Commit wait for external consistency waits until latest < now on every node. 2PC across groups handles cross-split transactions. Read variants: strong (linearizable, expensive), bounded staleness (cheap, allows lag), stale (fastest, returns timestamp).
The lower rows are ops. Split management rebalances loaded splits. Observability exposes latency + hotspot metrics. Ops covers schema design (interleaved tables, primary key), and cost.
End-to-end flow
End-to-end: a client inserts a row. Spanner assigns to a split's Paxos group; leader commits via Paxos; commit-wait ensures external consistency. Cross-region single-directory write: ~50ms latency in a regional config. Cross-directory write: 2PC across groups, higher latency. Read with staleness = 5s: no TrueTime wait, fast. Strong read across regions: pays TrueTime wait + Paxos round.