Lesson 2: The Standard Workload Profile

Why you need a profile before you need a service

In L1 you saw the whole Azure database map: relational, distributed SQL, key-value and document, wide-column, in-memory, graph and time series, and migration. That map is a menu. A menu doesn't help until you know what you're hungry for.

The usual mistake is to start with a product ("we're a Postgres shop", "Cosmos DB scales") and then justify it. Experienced engineers turn it around. They describe the workload first, in numbers, and then test each service against that description. This lesson builds that description: a standard workload profile. Every service lesson after this one checks the service against the same twelve items.

Think of it as a tenancy application for your data. A landlord won't accept "I earn quite a lot." They want a figure.

The twelve items

Walkthrough: from adjectives to numbers

Here's a realistic request from a product owner for an order-tracking service:

"It needs to be fast, always up, work globally, and not cost a fortune."

Every word in that sentence is an adjective, so none of it can be tested. Convert each one, starting with measured data. If the system already runs on PostgreSQL, pg_stat_statements tells you what the database actually does:

-- Top statements by call count since the stats were last reset
SELECT left(query, 60)              AS query,
       calls,                         -- how often it ran
       round(mean_exec_time::numeric, 2) AS mean_ms,  -- average, NOT p99
       rows
FROM   pg_stat_statements
ORDER  BY calls DESC
LIMIT  5;

Then turn daily volumes into a peak rate. Averages hide peaks, so apply a peak factor taken from your own traffic graphs:

orders_per_day   = 2_000_000      # from the business
reads_per_order  = 12             # status checks, from app logs
writes_per_order = 4              # create, pay, ship, deliver

secs = 86_400
avg_reads  = orders_per_day * reads_per_order  / secs   # ~278/s
avg_writes = orders_per_day * writes_per_order / secs   # ~93/s
peak_factor = 4                   # measured: busiest hour vs daily average

print(round(avg_reads * peak_factor), round(avg_writes * peak_factor))
# 1111 370  -> design for ~1,100 reads/s and ~370 writes/s, a 75/25 mix

Availability percentages also become concrete once you turn them into minutes:

for sla in (99.9, 99.95, 99.99, 99.999):
    mins = (1 - sla/100) * 365 * 24 * 60
    print(f"{sla}% -> {mins:.1f} min/year")
# 99.9%   -> 525.6 min/year (~8.8 h)
# 99.95%  -> 262.8 min/year (~4.4 h)
# 99.99%  -> 52.6 min/year
# 99.999% -> 5.3 min/year

Now write the profile down as a file you keep in the repo and reuse:

# workload-profile.yaml : order tracking, v1, 2026-10-25
data_model: relational; orders, lines, shipments; joins on order_id
read_write_mix: 75/25
peak_qps: { reads: 1100, writes: 370 }
latency: { p99_read_ms: 50, p99_write_ms: 100 }   # "fast" made testable
transactions: multi-row ACID on payment; read-your-own-writes on status
size: { today_gb: 180, growth_gb_month: 12 }       # ~610 GB in 3 years
scaling: single writer fine today; shard key candidate = customer_id
availability: 99.95%                                # "always up", agreed
rpo: 5 min            # data loss we can tolerate
rto: 1 h              # time to be serving again
multi_region: reads in EU + US; writes EU only      # "global", clarified
engine: PostgreSQL 16, uses PostGIS extension
workload_type: OLTP; nightly report could move to a replica
team: strong Postgres, no SQL Server DBA
cost: ceiling 4,000/month, steady load -> reserved capacity OK

Gotcha: average vs p99. mean_exec_time is an average. Users feel the slow tail, so set targets at p95 or p99 and measure them at the application, where network time is included.

Gotcha: "global". Ask whether users need to write in several regions or only read close to home. Local reads are cheap and common. Writes in several regions are a different architecture.

Knockout items: rule services out first

Most profile items only affect the score. A few are knockouts: a single answer removes whole services before you compare anything else. Check these first.

1. Engine lock-in. If the app depends on T-SQL stored procedures, PostgreSQL extensions such as PostGIS, Oracle PL/SQL or Cassandra CQL, any service that doesn't speak that engine is either out or needs a rewrite project.
2. RPO and RTO across regions. Cross-region replication is usually asynchronous. Microsoft's Azure SQL Database documentation, for example, puts geo-replication RPO at "equal to or greater than 0". The real figure depends on changes not yet replicated when the region fails. Restoring from geo-replicated backups can take minutes to hours. A hard "zero data loss if a whole region fails" requirement rules out many configurations straight away.
3. Multi-region writes. Most managed relational setups have one writable primary and readable secondaries. If the business truly needs writes accepted in several regions at once, the shortlist shrinks quickly. Cosmos DB, for example, offers multi-region writes, with a 99.999% read and write availability SLA in that configuration.

In our profile, PostGIS and the 5-minute RPO matter most. Multi-region writes are not needed, and confirming that with the business keeps a lot of options open.

Best practice: For each knockout, record who agreed to the number and when. "RPO 5 min, agreed by Head of Ops, 2026-10-25" carries weight. "RPO low" carries none.

Trade-offs to keep honest

• Each extra nine of availability, or each step down in RPO, usually adds a replica, a region or a higher tier. Put a price next to each one.
• Stronger consistency costs latency and availability in distributed systems. Cosmos DB, for instance, offers five levels: Strong, Bounded staleness, Session, Consistent prefix and Eventual. Decide what each user flow actually needs.
• Team skills are a real constraint. A technically better engine the team can't operate is a risk.

Key takeaways

• Describe the workload before picking a service, using the same twelve items every time.
• Use measurements: peak QPS from logs, p99 latency, GB and growth per month, RPO and RTO in minutes, budget per month.
• Convert SLA percentages into minutes per year (99.99% ≈ 52.6 min) so stakeholders know what they're asking for.
• Check knockouts first: engine lock-in, cross-region RPO/RTO and multi-region writes.
• Keep the profile as a versioned file. Every later lesson tests a service against it.