Fisheries VMS Domain · Lesson 13 of ∞ · Second pass · ← Lesson 12
Second pass · the numbers, decoded
Lesson 3 asked "which legal obligation is this NFR serving?" This lesson answers that question for every number in e-Boat's own README, one at a time.
e-Boat's README states six numeric targets up front. Read individually they're generic reliability-engineering boilerplate. Read against everything in this workspace so far, each one is a specific answer to a specific domain question.
| Metric | Target |
|---|---|
| Production availability | 99.5% per month |
| API response latency | p95 ≤ 5s, p99 ≤ 10s |
| Device-to-map latency | ≤ 30s |
| RTO / RPO | ≤ 30 min / ≤ 5 min |
| Ingest throughput | 200 msg/s sustained, 500 msg/s burst |
| Concurrent monitoring objects | 10,000 |
99.5% availability allows roughly 43.8 hours of downtime per year — about 3.6 hours a month. That's a real, meaningful gap compared to 99.99% ("four nines," ~52 minutes/year), and it's worth asking why a monitoring system with a legal enforcement duty wouldn't target higher. Two reasons compound here. First, cost and complexity scale steeply per additional "nine" — going from 99.5% to 99.99% is not a 0.49-percentage-point improvement in effort, it's an order-of-magnitude jump in redundancy engineering. Second, and specific to this deployment (Lesson 11): infrastructure serving a fleet operating in an active conflict zone faces failure modes — power, connectivity, physical infrastructure risk — that no amount of software redundancy fully insures against. Setting 99.5% is choosing an honest, achievable target over an aspirational one that a wartime operating environment would likely violate anyway.
Source: SLA uptime calculator — 99.5%.
Covered in Lesson 3: this traces to UNFSA's duty to investigate alleged violations promptly. Worth restating here because it's the cleanest example of the pattern this whole lesson is about — a number that looks like ordinary UX polish is actually the technical form of an international legal obligation.
RTO (Recovery Time Objective) is how long the system can be down before it's back. RPO (Recovery Point Objective) is how much data you can afford to lose. e-Boat's ≤30 min / ≤5 min split says: after a failure, get the system running again within half an hour, and lose no more than the last five minutes of telemetry. The tender's own infrastructure assumptions ground this in a specific mechanism — asynchronous NATS stream mirroring to a secondary data centre plus Velero volume snapshots — rather than leaving it as an abstract promise. Note the asymmetry: RTO (30 min) is six times looser than RPO (5 min), which reflects a judgement that a short visible outage is more tolerable than losing a meaningful stretch of position history for an active fleet.
Source: Druva — Understanding RPO and RTO.
Here's a genuinely interesting inconsistency worth noticing, not glossing over: Lesson 7 established that NOAA's national VMS — the largest documented national VMS fleet in the world — covers roughly 4,000 vessels. e-Boat's ToR targets 10,000 concurrent monitoring objects, more than double that. Two explanations are plausible and worth distinguishing rather than assuming: either "monitoring object" in this ToR is deliberately broader than "licensed fishing vessel" (small craft, non-fishing vessels of interest, or a multi-year growth headroom target), or the number is simply an ambitious ceiling rather than a reflection of Ukraine's actual current fleet size. Worth confirming which, directly, rather than treating 10,000 as self-evidently "how big Ukraine's fishing fleet is."
These two numbers are the plumbing behind all of the above — they're what makes 10,000 concurrent objects and 30-second map latency simultaneously achievable rather than contradictory promises. The p95/p99 split (rather than a single average) is itself informative: it commits to a worst-case-minus-outliers bound, not just a typical-case number, which matters because an inspector deciding whether to intercept a vessel cares about the slow request they happen to be waiting on, not the system's average performance.
Something unclear, or want to go deeper on any term here? Ask the agent that built this lesson — it's your teacher for this workspace, not just a lesson generator.