# The Install Button Hides a Distributed System

## Reliability from published build to verified launchable state

Author: Jason Doyle

Drafted: 17 September 2026

> Disclosure: These views are my own and do not represent any current or former employer. This paper uses public documentation and published research. It does not describe private Steam architecture. The accompanying simulator uses synthetic client profiles and does not estimate Steam user performance.

## Executive summary

The Install button presents one action to the user.

The system behind it has to resolve a target build for a particular account and machine. It has to locate content, transfer missing data and reconstruct files on local storage. The result may still need prerequisites before the application can launch.

Steam provides a useful public case study. Steamworks documentation distinguishes applications, packages, depots, builds and branches.\[1\] A depot can be selected by operating system or language. Architecture and downloadable-content ownership can also change which files are mounted.\[2\] Builds carry depot manifests containing file metadata and SHA1 hashes.\[3\]

SteamPipe divides files into chunks of roughly one megabyte. New chunks are compressed and encrypted before upload. A client later downloads, decrypts and expands them.\[4\] HTTP delivery allows ordinary caches and external content-delivery providers to participate.\[4\]

That network path operates at very large scale. A 2024 measurement study collected public Steam infrastructure and traffic data every 30 minutes from February to October 2023. The authors reported average traffic of 15 terabits per second and peaks of 146 terabits per second.\[5\] Valve reported delivering about 100 exabytes to customers during 2025, up from about 80 exabytes in 2024. It also reported an average of 274 petabytes of installs and updates per day.\[6\]

Those figures establish the scale of distribution without showing whether a named client reaches a usable result.

The client path can be dominated by work that does not cross the network. Valve documents that SteamPipe builds the new version of a changed pack file alongside the old version. A ten-byte change to a 25 GB pack file still requires almost the whole 25 GB file to be copied locally before commit.\[4\] Storage hardware can therefore control completion time after a tiny download.

File layout can also expand the network work. SteamPipe searches for unchanged chunks when preparing an update. Offset changes in a distributed pack-file table of contents can make many fixed chunks appear new. Valve states that this can cause changes to a few assets to require more than half of the file to be downloaded. Asset shuffling creates a related problem because SteamPipe does not know asset boundaries.\[4\]

The engineering outcome should be defined beyond transfer:

> Reliable software distribution moves a named client from an allowed starting build to a verified launchable state within a stated time.

The old state should remain recoverable until the new state is ready to be committed.

For this paper, a verified launchable state means:

- the target build has been selected for the client;
- required content is present and committed;
- the integrity checks represented by the delivery contract have completed;
- required installation actions have succeeded;
- the application is eligible to launch.

This proposed measurement boundary is not a Steam term.

The paper contributes a reproducible sensitivity model for the path between transition admission and launchable state. The model treats network, CPU and disk as separate resources whose work may overlap. It reports a lower bound set by the busiest resource and a serial upper bound. A declared overlap assumption places the illustrative result between those bounds.

The simulator includes six synthetic scenarios. In the scenario based on Valve's 25 GB pack-file example, a one MiB model chunk crossed a fast network while the client rebuilt the pack file on slower storage. The simulated median time to launchable state was 7 minutes 24 seconds. The same content and network assumptions on faster storage produced a median of 29 seconds. Disk was the bottleneck in every run of both scenarios.

Another scenario modelled hostile pack-file layout. A 10 MiB logical change produced a 12.5 GiB download and rebuilt a 25 GiB file. Network time then controlled the critical path, with a simulated median of 14 minutes 32 seconds under the declared rates.

These model outputs use synthetic inputs and carry no claim about observed Steam performance. They show how the dominant resource changes with client state. Download size alone cannot identify that shift.

A distribution SLO should therefore combine completion and latency:

- the fraction of eligible clients that reach launchable state before a deadline;
- p50 and p95 time to launchable state;
- blocked transitions caused by storage, integrity or prerequisite failures;
- network patch amplification;
- local read and write amplification;
- retry work and wasted transfer.

Developers influence several of these measures through asset layout and depot design. The platform influences release controls, metadata and delivery options. Client hardware and local state remain part of the result.

The Install button exposes one result across that combined system. Download throughput measures only part of the transition.

## 1. The button represents a state transition

A user sees a game in a library and selects Install.

That interaction does not identify one file. It requests a transition from the current local state to a target state permitted for that user and device.

The starting state can include:

- the installed build, if any;
- account entitlements;
- selected branch;
- operating system and architecture;
- interface language;
- owned downloadable content;
- cached chunks;
- free storage;
- local prerequisites.

The target state depends on several of the same inputs.

Steamworks separates an application from the packages that grant ownership. Packages refer to depots, while builds record versions of depot content. Branches decide which build is active for a group of users.\[1\]

This structure means that two owners of the same application may receive different content. One client may need a language depot that another client does not. Platform-specific binaries can be separated by operating system. Downloadable content may add another depot.\[2\]

The button therefore asks the platform to resolve a content plan.

That plan crosses several independently changing systems:

| Area | State that affects the transition |
| --- | --- |
| Developer release | Depot contents, build, branch and prerequisites |
| Platform metadata | Entitlement, manifest and active build |
| Distribution | Cache availability, available chunks and network path |
| Client | Existing files, cache, free space and resource rates |
| Application | Required content and first-launch requirements |

The term distributed system is sometimes reserved for services that coordinate several computers at runtime. This paper uses it in the broader engineering sense: the result depends on components with independent state and failure. Ownership is also split across those components. The state transition still has to be measured end to end.

## 2. Public Steam concepts expose the plan

Steam's public documentation provides enough detail to describe the delivery contract without claiming access to private implementation.

### 2.1 Depots resolve the content set

A depot is a logical group of files delivered as one unit. Steam can select depots by language, operating system and architecture. Downloadable content can be managed through separate depots.\[2\]

Depot order also matters. Later-mounted depots override files from earlier ones.\[2\]

The installed application is a composition resolved for each client.

This distinction affects reliability. A test performed against one depot composition does not automatically cover another. Missing an operating-system depot can leave owners unable to download content for that platform.\[2\]

### 2.2 Builds and manifests identify a release

A build represents the content of one or more depots at a point in time.\[3\]

Each depot build produces a manifest. Valve describes the manifest as a file list with metadata that includes size, SHA1 hash and flags.\[3\] During a build, a final manifest is generated for each depot version and identified by a unique 64-bit manifest ID. The Master Depot Server assigns a global BuildID after all depots have been processed.\[4\]

The manifest separates identity from transport. A cache can supply bytes, while the manifest states which bytes belong to the target.

This is one reason a download cannot be treated as an unstructured stream. The client is converging on a named release.

### 2.3 Branches control exposure

The default branch is the version delivered to ordinary customers. Other branches can hold test builds or optional versions.\[7\]

Valve recommends uploading an update to a password-protected test branch before promoting it to the default branch.\[8\] A released application also requires an additional authorisation step before a build becomes live on the default branch.\[3\]

These controls reduce release risk. They do not remove client diversity after promotion.

When a build becomes default, each eligible client still starts from its own local state.

## 3. Transfer is one stage of the transition

SteamPipe divides each file into chunks of roughly one megabyte. It compresses and encrypts new chunks before uploading them.\[4\]

For an update, the build process searches for chunks that match the previous version. Ideally, only new or modified chunks need to be transferred.\[4\]

This design reduces network work when file layout remains stable.

### 3.1 HTTP makes the data plane extensible

SteamPipe uses HTTP for content delivery. Valve notes that ordinary third-party HTTP caches can improve download speed. External CDN providers can also host content.\[4\]

Valve's local content-server documentation shows a useful separation. Depot chunks can be served from an ordinary local HTTP server. At build time, the depot builder still contacts Steam's Master Depot Server and uploads only depot metadata, while local content remains managed through the Steamworks site. Valve states that depot content is always encrypted on the local server, as it is on public content servers. Anyone obtaining those chunks could not decrypt them without the depot decryption keys.\[9\]

Content origin and release authority are separated in that design.

### 3.2 Global scale creates burst pressure

Visser and Fontugne studied Steam's public APIs and traffic statistics over nine months in 2023.\[5\] Their study maps cache locations, observes how advertised sources shift under load and estimates the resulting third-party CDN offload.

The same study installed a title through SteamCMD on five virtual machines and published logs with per-source throughput and cache hit rates. Those client logs validated the authors' API inference. The study did not analyse time to launchable state, retry behaviour or reconstruction cost as outcomes.\[5\]

The study reports:

- 44.7 exabytes delivered in 2022, citing Valve's own disclosure;
- average traffic of 15 terabits per second during the collection period;
- peaks up to 146 terabits per second;
- an 85-terabit-per-second peak during the Counter-Strike 2 release.\[5\]

The 146-terabit figure is the overall peak reported for the study period. The 85-terabit figure is specific to the Counter-Strike 2 case.

The study already covers the server-side questions in depth. It examines cache load, regional capacity and third-party CDN overflow. Repeating that map would add little.

Valve's later review reported delivering about 100 exabytes to customers during 2025, compared with about 80 exabytes in 2024.\[6\] The scale has continued to grow.

Those aggregate figures leave the client-side question unanswered: what happened after one machine received its share of the traffic?

### 3.3 Throughput is necessary and incomplete

Network throughput remains important. A cold install can contain tens of gigabytes with little reusable local content.

Throughput does not identify:

- whether the correct release was selected;
- whether chunks can be reused;
- how much local data must be copied;
- whether enough temporary space exists;
- whether installation actions succeed;
- when the application becomes eligible to launch.

Transfer throughput does not answer those questions.

## 4. Local reconstruction can dominate

SteamPipe's public documentation describes the client-side pack-file update sequence.

The system builds a new version of a changed pack file alongside the old version. After all new files are built, it commits the update by deleting old files and moving new files into place.\[4\]

Valve gives a concrete example. A ten-byte change to a 25 GB pack file still causes almost the whole 25 GB file to be copied from the old version into the new one. The result can be slow on some client storage hardware.\[4\]

The old file remains present during reconstruction, and Valve lists offline availability after an update download starts as a SteamPipe feature.\[4\] The retained state has a storage cost. The same mechanism can separate downloaded bytes from written bytes by several orders of magnitude. Free-space requirements then follow the reconstruction plan rather than the transfer size.

Valve does not publish the client's general free-space calculation. The exact preflight rule should not be inferred from one example. The example still proves that a small network patch can require a large temporary local file.

### 4.1 Network patch amplification

Let:

```text
A_network = downloaded bytes / logically changed bytes
```

A value near one means network work is close to the source change. A large value means packaging or chunk boundaries expanded the transfer.

Fixed chunking is sensitive to byte movement. The Low-Bandwidth Network File System paper explains the general problem: inserting a byte near the start of a file shifts later fixed block boundaries, changing their hashes.\[10\] Content-defined chunking was developed to reduce that sensitivity.

SteamPipe uses fixed chunks and documents the practical consequence for pack files. If a table of contents stores absolute offsets, a small asset growth can change later offsets. Each changed offset can cause another chunk to become new. Valve states that a few asset changes can require more than half of a pack file to be downloaded.\[4\]

The developer's packaging format therefore contributes to the user's network cost.

### 4.2 Local write amplification

Let:

```text
A_write = bytes written locally / bytes downloaded
```

In the 25 GB example, the client may download one changed model chunk while writing a new 25 GB file.

The same reconstruction also reads the reusable content from the old file. The simulator records read bytes separately.

In the simulator, the Valve example uses one MiB of compressed transfer and 25,000,000,000 bytes for the touched file. Under those assumptions:

```text
A_write = 23,841.86 MiB / 1 MiB
        = 23,841.86
```

The logical change is ten bytes, so the modelled network amplification is:

```text
A_network = 1 MiB / 10 bytes
          = 104,857.6
```

These ratios describe the scenario. Valve's documentation gives a chunk size of roughly one MB, so the one MiB model chunk is an explicit modelling choice rather than a measured Steam value.

### 4.3 Storage headroom is part of availability

A client with insufficient staging space cannot complete the transition even when the network is healthy.

The relevant condition is:

```text
available free space >= extra space required by the reconstruction plan
```

The extra-space term can be large when a changed file is rebuilt beside its predecessor.

An availability measure that ignores local storage will count such a client incorrectly. The content service may be reachable and fast while the application remains unavailable to that user.

## 5. Launch requires more than committed files

Some applications require local actions before their first successful launch.

Steam install scripts can create registry values or run prerequisite installers on Windows. Valve states that install scripts are cryptographically signed at build time and that Steam validates the signature before executing any install script. Signing is also required for privileged operations such as writing to the HKLM registry hive.\[11\]

Steam also offers common redistributables including Microsoft Visual C++, .NET, DirectX 9, OpenAL, XNA and PhysX. Valve creates and maintains their install scripts. Developers opt in per application, and Steam installs a selected redistributable only if necessary.\[12\]

These stages illustrate a wider point. Content presence does not prove runtime readiness.

Valve's update guidance says that players with the game installed must download each update before launching again.\[8\] The visible product outcome is therefore gated on the whole transition.

The measurement stops at launch eligibility. A successful process start does not mean the game is playable in every product sense. Login, shader compilation and service availability may create later gates. Those belong to a broader time-to-first-session measure.

## 6. Define a verified launchable state

An engineering measure needs a precise end state.

For a client `c` and target build `b`, define:

```text
G(c, b) =
    target build selected
    AND required content committed
    AND required integrity checks passed
    AND required installation actions completed
    AND launch permitted
```

The expression is a proposed contract. Implementations can refine each term.

The start of the measurement must also be named. A useful point is transition admission: the moment the client accepts the work into its queue or active execution.

Time to launchable state is then:

```text
TTLS(c, b) = time(G(c, b)) - time(transition admitted)
```

Clients that never reach `G` need a terminal reason rather than an infinite duration hidden from the dataset.

Candidate reasons include:

- insufficient free space;
- manifest or integrity failure;
- exhausted transfer retries;
- local write failure;
- prerequisite failure;
- user cancellation;
- target build withdrawal.

### 6.1 Keep the old state recoverable until commit

Valve's pack-file description shows one method: reconstruct the new file beside the old one, then commit after reconstruction completes.\[4\]

Other update systems make the same reliability choice with different storage structures.

Android A/B updates write into an inactive slot, which is a second set of partitions, while the system keeps running from the current slot. If the update fails or the new slot does not report a successful boot, the bootloader returns to the old slot.\[13\]

OSTree stores complete filesystem trees in a content-addressed repository. Deployments share unchanged files through hard links, allowing multiple versions to remain installed with space cost concentrated on new files.\[14\]

These designs separate preparation from activation.

The shared invariant is:

```text
an incomplete target must not destroy the last usable state
```

The cost may appear as temporary storage, duplicate writes or retained objects. Reliability engineering should record it as part of the transition.

### 6.2 Launchable can be a subset

Some platforms allow an application to launch before all optional content arrives.

Microsoft's Game Development Kit defines a launch set. The platform ensures that this subset is present before registering the title as available for launch. Remaining chunks can continue installing while the title runs.\[15\]

This creates two goal states:

```text
G_launch = minimum content required to launch
G_complete = all selected content installed
```

Steam's public update guidance says an installed owner must receive an update before launching the game again.\[8\] It does not document a general launch-set mechanism for Steam content.

The simulator therefore uses all touched content as the launch gate. A launch-set variant would test a different contract and make no claim about Steam.

## 7. Model the critical path

A serial model adds the stage durations:

```text
T = T_network + T_cpu + T_disk + T_commit
```

That equation assumes serial work.

Clients can overlap some transfer, decompression and local writes. The exact overlap depends on implementation and contention. A network-bound install may stream data to disk while more chunks arrive. A disk-bound reconstruction may continue after the final network byte.

The paper uses a resource envelope.

Let:

```text
N = network work in seconds
C = CPU work in seconds
D = local disk work in seconds
```

The optimistic pipeline bound is:

```text
T_lower = max(N, C, D)
```

The serial upper bound is:

```text
T_serial = N + C + D
```

Overlap is declared as a fraction `o` between zero and one:

```text
T_pipeline =
    T_lower
    + (1 - o) * (T_serial - T_lower)
```

An overlap of one uses the lower bound. An overlap of zero uses the serial bound.

This interpolation is a modelling assumption. It does not claim to reproduce Steam's scheduler.

Sequential overhead is then added:

```text
TTLS =
    T_metadata
    + T_pipeline
    + T_commit
    + T_post_install
```

### 7.1 Network work

For transferred bytes `B_transferred`, meaning the compressed download plus retried chunks, and effective client rate `R_network`:

```text
N = 8 * B_transferred / R_network + retry delay
```

Retries increase both transferred bytes and elapsed time.

Each attempt uses the failure probability declared by the scenario. A failed attempt transfers one average compressed chunk again. Jobs of up to 4,096 chunks are sampled attempt by attempt. Larger jobs, including the interrupted scenario, use a normal approximation to the sum of geometric retry counts with the same mean and variance. The failure probability remains a sensitivity input because public Steam data does not provide per-client retry measurements.

### 7.2 CPU work

The public SteamPipe description names decrypt and expand operations on the client.\[4\] Valve documents that manifests carry SHA1 hashes,\[3\] but it does not publicly document whether, when or over what scope the client verifies those hashes during an update. The verification term below is a modelling construct for the cost of an integrity pass. It is not a documented Steam stage.

CPU work combines decompression and an abstract integrity pass:

```text
C =
    changed uncompressed bytes / decompression rate
    + changed uncompressed bytes / verification rate
```

The rates are synthetic and configurable.

### 7.3 Disk work

For a touched file set:

```text
D =
    reused bytes / read rate
    + new file bytes / write rate
```

The model assumes one local device, so reads and writes are added within the disk resource. It does not model filesystem caching or device-internal parallelism.

This term captures Valve's documented rebuild-alongside behaviour for pack files.\[4\]

## 8. Reproducible sensitivity model

The easiest way to run the model is to download and extract the [`update-simulator-bundle.zip`](./update-simulator-bundle.zip) file. It contains the script, scenario inputs and a short README.

The individual artifacts remain available:

- [`simulate_update.py`](./simulate_update.py);
- [`update-scenarios.json`](./update-scenarios.json);
- [`update-simulation-runs.csv`](./update-simulation-runs.csv);
- [`update-simulation-summary.csv`](./update-simulation-summary.csv).

It uses only the Python standard library and performs no network access.

Run:

```text
python simulate_update.py --self-test
python simulate_update.py
```

The artifact digests are:

| Artifact | SHA-256 |
| --- | --- |
| `update-simulator-bundle.zip` | `9e23be7bde7ff50bbf231718aaec8926cb5b95eb36feb3416453f795ccd6f342` |
| `simulate_update.py` | `2bd0aaf71440c09fc3ca153985e2a99f97a9d4376d5c46b1b1f969ccafe48a0e` |
| `update-scenarios.json` | `82e1475ca7c7edc2785b7402f70e50eb615b2dab026c1b7bdef928af442be8ce` |
| `update-simulation-runs.csv` | `be81be2fe9ee854dfff1b7a05ce6604bc04314630afc6e350d334d4004c5cf84` |
| `update-simulation-summary.csv` | `a199f0363fbc9d5802b316ce54764bdbc12e4743923798ae2db4f0217887e053` |

The generated run file contains 6,000 rows. Each row records the model and Python versions alongside sampled rates, work by resource, retry count, amplification, bounds and outcome.

### 8.1 What comes from public evidence

Documented mechanics in the model are:

- chunked content delivery;
- changed-chunk reuse;
- compressed transfer followed by local expansion;
- pack-file reconstruction beside the old file;
- commit after reconstruction;
- fixed-boundary patch amplification.

The source for those mechanics is Valve's SteamPipe documentation.\[4\]

### 8.2 What remains synthetic

The following inputs are assumptions:

- network rate distribution;
- local read and write rates;
- decompression and verification rates;
- overlap between resources;
- attempt failure probability;
- retry delay;
- deadline;
- available free space.

Each scenario records bounded values for those inputs.

Triangular distributions keep each synthetic range transparent and bounded. The mode is the most likely value, while the low and high values define the sensitivity range.

No public dataset identified for this paper reports Steam client completion time, retry rate or storage-device mix. The outputs must not be read as population estimates.

### 8.3 Scenario definitions

| Scenario | Changed input | Download | Touched local content | Purpose |
| --- | --- | --- | --- | --- |
| Fast network, slower disk | 10 bytes | 1 MiB | Valve's 25 GB pack file | Isolate local reconstruction |
| Fast network, faster disk | Same | Same | Same | Hold content constant and change storage |
| Hostile layout | 10 MiB | 12.5 GiB | 25 GiB | Show network patch amplification |
| Cold install | 50 GiB with no reusable local content | 50 GiB | 80 GiB | Show a network-bound case |
| Interrupted update | 2 GiB logical | 5 GiB | 12 GiB | Expose retry sensitivity |
| Insufficient space | 10 bytes | 1 MiB | Valve's 25 GB pack file | Show a blocked transition |

The two 25 GB scenarios preserve Valve's decimal byte count. The hostile-layout scenario is synthetic and uses binary GiB units.

### 8.4 Output metrics

Each run reports:

- modelled time to launchable state;
- lower and serial pipeline bounds;
- network, CPU and disk work;
- critical resource;
- bytes downloaded again through retries;
- bytes read and written locally;
- extra-space requirement;
- deadline attainment;
- terminal status.

The summary reports nearest-rank p50, p95 and p99 values across 1,000 runs per scenario.

These percentiles describe the declared synthetic distributions. They do not describe Steam users.

## 9. Results

The bottleneck moves across the scenario set.

| Scenario | Modelled p50 | Modelled p95 | Critical resource |
| --- | --- | --- | --- |
| Fast network, slower disk | 7 min 24 sec | 8 min 40 sec | Disk in 100% of runs |
| Fast network, faster disk | 29 sec | 35 sec | Disk in 100% of runs |
| Hostile layout | 14 min 32 sec | 19 min 22 sec | Network in 100% of runs |
| Cold install | 70 min 11 sec | 89 min 48 sec | Network in 100% of runs |
| Interrupted update | 10 min 1 sec | 11 min 55 sec | Network in 100% of runs |
| Insufficient space | Blocked | Blocked | No launchable run |

### 9.1 The same patch can have a fifteen-fold storage effect

The first two scenarios use the same logical change, download and touched file. They differ only in synthetic read and write rates.

The slower-storage scenario has a modelled p50 of 443.94 seconds. The faster-storage scenario has a p50 of 29.39 seconds.

The ratio is 15.1.

Network time is about eight milliseconds in each median run. A download-speed dashboard would show success while the user's wait was controlled by disk work.

The result does not predict an HDD or NVMe benchmark. It demonstrates sensitivity to a variable that transfer metrics omit.

### 9.2 Packaging can move the bottleneck back to the network

Hostile file layout produces a 12.5 GiB download for a 10 MiB logical change in the third scenario.

Its network amplification is:

```text
12.5 GiB / 10 MiB = 1,280
```

Network work controls every run under the declared profile. The p95 reaches 19 minutes 22 seconds.

The scenario is consistent with Valve's warning that small asset changes can require more than half of a pack file to be downloaded.\[4\]

The mechanism is documented, while the exact amplification remains synthetic.

### 9.3 Retry assumptions change the tail

Retry sensitivity is modelled with a five per cent probability, `0.05`, on each chunk attempt.

That scenario contains 8,192 uncompressed model chunks. The expected total retry count under the geometric model is about 431. The observed mean across 1,000 seeded runs is 431.58.

Those retries add bytes and delay. The scenario's p50 is 10 minutes 1 second, while p95 is 11 minutes 55 seconds.

Real failure probabilities and retry policy are private or unavailable. The scenario exists to show which telemetry would be needed.

### 9.4 Free space is a binary gate

The final scenario uses the same transfer and touched file as the slower-disk example. It gives the client only 20,000,000,000 bytes of free space.

The model requires enough room for the 25,000,000,000-byte reconstructed file. Every run is blocked before launchable state.

Increasing bandwidth cannot change that result.

## 10. Measure the client transition directly

A production measurement should record state transitions directly.

Candidate timestamps include:

| Event | Question answered |
| --- | --- |
| Transition admitted | When did the client accept the work? |
| Content plan resolved | Which build and depots were selected? |
| First content received | When did transfer begin? |
| Required chunks present | When was network acquisition complete? |
| Reconstruction complete | When were target files prepared? |
| Commit complete | When did the target become active? |
| Prerequisites complete | When did local installation work finish? |
| Launch accepted | When did the platform permit launch? |

The record also needs dimensions:

- starting build and target build;
- branch and depot set;
- region and source class;
- client storage class;
- free-space band;
- retry count;
- failure reason.

Privacy and cardinality constraints may require aggregation. The raw event model should still preserve enough information to identify the blocking stage.

### 10.1 Completion is a yield measure

For eligible transitions during a window:

```text
completion within deadline =
    clients reaching G before deadline
    / eligible admitted clients
```

The denominator must include blocked clients. Excluding clients that run out of space would make the result look healthier by removing the failures most relevant to users.

Google's SRE guidance treats availability as the fraction of time a service is usable. It notes that this is often operationalised as the fraction of well-formed requests that succeed, a measure called yield. The same guidance recommends carefully defined SLIs and says client-side latency is often more user-relevant than server-side latency.\[16\]

### 10.2 Latency needs percentiles

An average hides slow clients.

Report at least:

- p50 TTLS;
- p95 TTLS;
- deadline attainment;
- terminal failure rate.

The percentile should be stratified by starting state. A cold install, a small patch and a branch switch are different operations.

### 10.3 Amplification identifies avoidable work

Network and write amplification explain why similar source changes produce different user costs.

Track:

```text
A_network = downloaded bytes / logical change bytes
A_write   = local bytes written / downloaded bytes
A_retry   = retry bytes / first-attempt bytes
```

Packaging drives the first ratio, reconstruction the second and delivery stability the third.

## 11. Ownership crosses organisational boundaries

No single actor controls the whole transition.

| Actor | Main controls | Evidence it should retain |
| --- | --- | --- |
| Developer | File layout, depot structure, prerequisites and build promotion | Patch size, touched-file set, branch tests |
| Platform | Manifest identity, release gate, content sources and rollback \[4\] | Build lineage, delivery result, client stage outcome |
| Network and CDN | Path capacity and cache availability | Transfer rate, source changes, retry causes |
| Client | Existing state, free space and local resources | Reconstruction time, write errors, prerequisite result |

This division complicates support.

A player may report that the platform is slow. The network transfer may already be complete. The client could be rebuilding a large file or waiting on a local installer.

A developer may ship a ten-byte content change. Its pack-file layout can still generate gigabytes of user work.

The platform needs enough evidence to distinguish those cases without exposing private user data.

## 12. Release engineering should include client-state evidence

Valve lets developers inspect update size before making a build live.\[4\]

SteamPipe also documents web-based rollback to a previous build.\[4\]

That check should be part of a wider release record:

- logical content changed;
- changed chunks produced;
- files touched;
- local bytes expected to be read and written;
- peak extra space;
- tested storage profiles;
- rollback build;
- measured TTLS on the test matrix.

The list is a recommendation for release engineering.

### 12.1 Test the previous states that exist in the field

Deployment risk depends on the states clients are leaving.

A client may be:

- on the current default build;
- several builds behind;
- on a beta branch;
- missing optional content;
- partially updated;
- carrying corrupt local data.

One test install cannot represent that set.

Build validation should cover the most common starting builds and the states with the largest consequence. It should evaluate the transition and the final file tree.

### 12.2 Packaging is a reliability decision

Valve recommends limiting the size of each pack file and keeping asset changes local within it.\[4\]

The reason is visible in both amplification ratios.

Stable layout reduces changed chunks, and smaller pack files reduce both local reconstruction and temporary space. Separating frequently changed content from stable content limits the blast radius of an update.

These are product reliability decisions made during asset packaging.

### 12.3 Urgent updates compound the transition load

Lin, Bezemer and Hassan studied 2,419 update notes from 50 popular Steam games. They classify an update as urgent when it is released zero days after the previous update, released faster than the game's regular cycle or described by the developer as a hotfix.\[17\]

An urgent hotfix can arrive while some clients are still converging on the previous build.

That creates another starting state. Release telemetry should separate clients that updated directly from the original build and clients that passed through an intermediate release.

## 13. What evidence is still missing

No public source identified for this paper reports a representative distribution of Steam client TTLS.

The missing evidence includes:

- completion and abandonment rates;
- stage-level latency;
- retry counts;
- free-space blocks;
- disk-write failures;
- client storage distribution;
- rebuild work by title and update;
- branch-to-branch transition cost.

The PAM 2024 study shows that useful Steam measurement can be built from public data. Its client logs validate infrastructure inference, but they do not report TTLS, retries or reconstruction cost. The authors also state that weighted-load semantics and cache internals were not available to them.\[5\]

A client study would need consented telemetry or a reproducible test fleet.

### 13.1 A useful field study

One design would recruit clients across declared hardware and network profiles.

For each test transition, record:

- signed build and manifest identifiers;
- initial file state;
- selected depot set;
- content-source changes;
- stage timestamps;
- read and write bytes;
- retry events;
- terminal status.

The analysis should pre-register one primary outcome, such as TTLS from a named starting build.

The study should publish the client harness and synthetic test title. A real commercial title can introduce licensing and redistribution constraints that prevent reproduction.

### 13.2 A platform study

A platform operator could answer a larger question:

> Which stage owns the p95 delay for each transition class?

A platform operator could report the result without publishing individual client data. Separate results would be needed for cold installs, ordinary updates, urgent hotfixes, branch switches and repair after corruption. Those observations could then replace the model's synthetic inputs.

## 14. The strongest counterargument

The proposed metric may assign too much responsibility to the distribution platform.

A platform can deliver the correct signed content quickly and still encounter a slow disk, a broken third-party installer or an application that fails during startup. Calling the whole result distribution reliability may blur ownership.

The objection is valid, which is why the event record must preserve stage attribution. TTLS is the customer outcome, while the record identifies which stage blocked it.

An end-to-end SLI does not require one team to own every cause. It requires the system to retain enough evidence to route the problem correctly.

There is also a terminology objection. A content-delivery workflow with a central release authority may not meet every academic definition of a distributed system.

The title describes the engineering surface hidden by the button. The substantive claim is narrower: launchability depends on state and failure across the release system, content network and client. That remains true regardless of the label.

## 15. What this paper does not claim

This paper does not claim:

- to describe private Steam architecture;
- that Steam uses the simulator's rates or overlap model;
- that the generated percentiles represent Steam users;
- that download throughput is unimportant;
- that every game requires all content before first launch;
- that launch eligibility proves a successful gameplay session;
- that one organisation owns every failure in the path.

It proposes a measurement boundary and a transparent sensitivity model.

## Conclusion

The Install button asks a distributed set of components to complete one user-visible transition.

Steam's public documentation shows that the path includes build selection, chunk delivery and local reconstruction. It can also include signed installation work before launch.\[1\]\[4\]\[11\]

The network operates at global scale, and prior research has already documented much of that infrastructure.\[5\] Client completion remains less visible.

Valve's 25 GB pack-file example shows why transfer metrics are insufficient. A tiny logical change can produce one small download and almost 25 GB of local copying.\[4\]

Reliable distribution should therefore be measured at a verified launchable state. Completion rate and TTLS show whether clients reach that state, while amplification metrics explain avoidable work.

The simulator demonstrates the consequence without claiming production measurements. Under one declared comparison, changing the storage rates moved median completion from 7 minutes 24 seconds to 29 seconds. Another scenario shifted the bottleneck to the network through hostile file layout.

The relevant result is the client's ability to launch the intended build, with arriving bytes recorded only as progress towards that state.

## About the author

Jason Doyle writes about reliable software, observability, incident leadership, applied AI and practical controls for systems that influence human and organisational decisions. He publishes at [jasondoyle.ie](https://jasondoyle.ie) and can be contacted at [contact@jasondoyle.ie](mailto:contact@jasondoyle.ie).

## References

1. Valve Corporation, _Applications_, Steamworks Documentation, accessed 17 September 2026, [https://partner.steamgames.com/doc/store/application](https://partner.steamgames.com/doc/store/application).
2. Valve Corporation, _Depots_, Steamworks Documentation, accessed 17 September 2026, [https://partner.steamgames.com/doc/store/application/depots](https://partner.steamgames.com/doc/store/application/depots).
3. Valve Corporation, _Builds_, Steamworks Documentation, accessed 17 September 2026, [https://partner.steamgames.com/doc/store/application/builds](https://partner.steamgames.com/doc/store/application/builds).
4. Valve Corporation, _Uploading to Steam_, Steamworks Documentation, accessed 17 September 2026, [https://partner.steamgames.com/doc/sdk/uploading](https://partner.steamgames.com/doc/sdk/uploading).
5. Christoff Visser and Romain Fontugne, _Inside the Engine Room: Investigating Steam's Content Delivery Platform Infrastructure in the Era of 100GB Games_, Passive and Active Measurement 2024, LNCS 14537, pages 32-60, DOI 10.1007/978-3-031-56249-5_2, [https://doi.org/10.1007/978-3-031-56249-5_2](https://doi.org/10.1007/978-3-031-56249-5_2), open manuscript [https://www.iijlab.net/en/members/romain/pdf/chris_pam2024.pdf](https://www.iijlab.net/en/members/romain/pdf/chris_pam2024.pdf).
6. Valve Corporation, _Steam Year In Review 2025_, Steamworks Development, 6 March 2026, [https://store.steampowered.com/news/group/4145017/view/528746884222682052](https://store.steampowered.com/news/group/4145017/view/528746884222682052).
7. Valve Corporation, _Branches_, Steamworks Documentation, accessed 17 September 2026, [https://partner.steamgames.com/doc/store/application/branches](https://partner.steamgames.com/doc/store/application/branches).
8. Valve Corporation, _Updating Your Game - Best Practices_, Steamworks Documentation, accessed 17 September 2026, [https://partner.steamgames.com/doc/store/updates](https://partner.steamgames.com/doc/store/updates).
9. Valve Corporation, _SteamPipe Local Content Server_, Steamworks Documentation, accessed 17 September 2026, [https://partner.steamgames.com/doc/sdk/uploading/local_content_server](https://partner.steamgames.com/doc/sdk/uploading/local_content_server).
10. Athicha Muthitacharoen, Benjie Chen and David Mazieres, _A Low-Bandwidth Network File System_, Proceedings of the 18th ACM Symposium on Operating Systems Principles, 2001, pages 174-187, DOI 10.1145/502034.502052, [https://doi.org/10.1145/502034.502052](https://doi.org/10.1145/502034.502052), manuscript [https://pdos.csail.mit.edu/papers/lbfs:sosp01/lbfs.pdf](https://pdos.csail.mit.edu/papers/lbfs:sosp01/lbfs.pdf).
11. Valve Corporation, _Install Scripts_, Steamworks Documentation, accessed 17 September 2026, [https://partner.steamgames.com/doc/sdk/installscripts](https://partner.steamgames.com/doc/sdk/installscripts).
12. Valve Corporation, _Steam Common Redistributables_, Steamworks Documentation, accessed 17 September 2026, [https://partner.steamgames.com/doc/features/common_redist](https://partner.steamgames.com/doc/features/common_redist).
13. Android Open Source Project, _A/B System Updates_, accessed 17 September 2026, [https://source.android.com/docs/core/ota/ab](https://source.android.com/docs/core/ota/ab).
14. OSTree Project, _OSTree Overview_, accessed 17 September 2026, [https://ostreedev.github.io/ostree/introduction/](https://ostreedev.github.io/ostree/introduction/).
15. Microsoft, _Streaming Installation and Intelligent Delivery: An Overview_, Microsoft Game Development Kit documentation, accessed 17 September 2026, [https://learn.microsoft.com/en-us/gaming/gdk/docs/features/common/packaging/overviews/streaming_install-intelligent_delivery?view=gdk-2604](https://learn.microsoft.com/en-us/gaming/gdk/docs/features/common/packaging/overviews/streaming_install-intelligent_delivery?view=gdk-2604).
16. Betsy Beyer et al., _Site Reliability Engineering: How Google Runs Production Systems_, chapter 4, _Service Level Objectives_, O'Reilly Media, 2016, [https://sre.google/sre-book/service-level-objectives/](https://sre.google/sre-book/service-level-objectives/).
17. Dayi Lin, Cor-Paul Bezemer and Ahmed E. Hassan, _Studying the Urgent Updates of Popular Games on the Steam Platform_, Empirical Software Engineering, volume 22, issue 4, 2017, pages 2095-2126, DOI 10.1007/s10664-016-9480-2, [https://doi.org/10.1007/s10664-016-9480-2](https://doi.org/10.1007/s10664-016-9480-2).