---
title: "Non-functional requirements: examples and targets"
description: "Turn 'fast' and 'highly available' into testable targets: p95 latency, throughput, availability windows, RPO and RTO, with example numbers to negotiate."
canonical_url: "https://fanout.sh/system/archive/non-functional-requirements"
md_url: "https://fanout.sh/system/archive/non-functional-requirements.md"
access: "public"
---

# Non-functional requirements: examples and targets

Turn 'fast' and 'highly available' into testable targets: p95 latency, throughput, availability windows, RPO and RTO, with example numbers to negotiate.

## Public overview

Non-functional requirements

Non-functional requirements describe the conditions a system must meet while doing its job: latency, throughput, availability, durability, consistency, security, cost, and operability. “The API works” is incomplete if it becomes unusably slow under the expected load.

The useful habit is to turn each vague expectation into something a test or production measurement can check. We will write a latency target, separate availability from recovery, and see how those targets affect the design.

Say what you measure

“The API should be fast” leaves several questions open. Which operation? How much traffic? How many slow requests are acceptable? Are we timing the database, the server, or the user's browser?

These are example targets to negotiate, not universal defaults:

Expectation A more useful target --- --- Fast reads At least 95% of eligible reads return the correct result within 50 ms at the server boundary under the stated peak load High throughput Sustain 10,000 writes per second; handle a 50,000-per-second burst lasting five minutes Available API 99.9% of eligible requests succeed over a stated monthly window Recoverable data After the specified disaster, lose no more than five minutes of writes and restore service within 30 minutes Fresh search 99% of committed documents become searchable within 30 seconds

The numbers do not finish the requirement. Define eligible requests, the observation window, and the failure conditions. A traffic test also needs realistic request sizes and a read/write mix; tiny requests at an idle database cannot establish performance for a busy product.

Our shortener exercise uses a different provisional latency limit: one second for at least 95% of eligible redirects at the app boundary, including its required event write. Keep that exercise assumption separate from the 50 ms example above.

Count slow and failed requests honestly

The 95th percentile, or p95, describes the point below which 95% of the measured response times fall. It says nothing about how bad the slowest 5% can be. A fast average can hide that tail.

For a user-facing target, count requests that produce the correct answer within the deadline. Failed or timed-out eligible attempts are misses, even if the server returned an error quickly. Otherwise, a failing service can appear to improve its latency.

Choose the measurement boundary deliberately. Server logs help explain application work, but omit a request that cannot reach the server. Browser measurements include more of the user's experience and also depend on network conditions. Keep the two measurements labeled; a database timing is not a page-load promise.

Separate availability, data loss, and recovery time

Availability asks whether an operation is usable. Durability asks whether acknowledged data survives. A service can answer requests while having lost yesterday's records, or retain every record while temporarily unable to serve them.

Recovery targets make a failure scenario concrete. The recovery point objective , RPO, limits the acceptable gap in recovered data, expressed in time. The recovery time objective , RTO, limits how long restoring service may take. Name the scenario and when the clock starts: a process restart, a lost disk, and a lost region require different recovery plans.

---
This representation contains public Fanout content only. Protected Pro lessons, account data, billing, checkout, and pricing are not included.

Browse the public content map: https://fanout.sh/sitemap.md