Skip to content

Workload Model

Overview

This note defines the expected workload for the URL shortener system. It is intentionally limited to traffic shape, capacity targets, and consistency expectations.

This note does not describe service topology, storage design, cache design, or any other concrete implementation details. Those belong in separate architecture and component design notes.

Workload Assumptions

The system is sized around a write-to-read ratio of 1:10.

In practical terms:

  • one write represents one URL creation request
  • one read represents one redirect request
  • for every newly created short URL, the system is expected to serve ten redirect lookups

This makes the system explicitly read-heavy.

Capacity Targets

The workload model assumes the system must sustain the following steady-state targets under peak load:

Metric Target
URL creation throughput 1,024 QPS
Redirect throughput 10,240 QPS
Write-to-read ratio 1:10

These values are planning targets for system sizing and performance design.

For the generated short-code path, the 1,024 QPS write target is a deliberate generator-side ceiling derived from the Tinyflake bit budget and the requirement that generated Base58 short codes stay within 7 characters. It should not be read as an estimate of the database's maximum insert throughput. See Tinyflake Throughput for the full derivation.

Write Workload

The write workload is the traffic generated by URL creation requests.

The system must support:

  • sustained write throughput of 1,024 requests per second
  • continued operation at that rate without degrading the read path below its target throughput

This write workload includes the full create path from accepting a URL creation request to making the new short URL available to the system.

Read Workload

The read workload is the traffic generated by redirect requests.

The system must support:

  • sustained read throughput of 10,240 requests per second
  • a workload shape where reads dominate writes by a factor of ten

Because redirect traffic is expected to dominate the system, read scalability should be treated as the primary capacity driver.

Consistency Requirements

The system targets eventual consistency, not strong consistency.

In particular:

  • the system does not require strict read-after-write consistency
  • a newly created short URL may not become visible to every read path immediately
  • redirect requests issued shortly after creation may temporarily observe stale or not-yet-visible data

This behavior is acceptable for the current workload and business requirements.

Design Implications

This workload model leads to the following design requirements:

  • the system must be optimized for read-heavy traffic
  • the system must be sized for 10,240 QPS on the redirect path
  • the system must still sustain 1,024 QPS on the create path under the same workload envelope
  • the system may trade strong consistency for higher throughput and simpler scaling behavior