# Internet Service-Area 20/80 Hotspot SOP

Issue: [#198](https://github.com/tidbcloud/TiPoC/issues/198)

## Purpose

This scenario concentrates approximately 80% of selected Internet business
roots on exactly 20% of the prepared `service_area` key set. It supports Ride,
Food, Mart, every two-domain subset, and all three domains through the existing
Internet selected-business contract.

The hotspot changes only deterministic consumer selection. Ride, Food, and Mart
continue through their production root builders, state machines, transaction
factories, and TiDB SQL projection. The implementation does not add workload-
specific SQL to `core`, and it does not create a second operation lifecycle.
Big Query and Missing Index remain third-layer operations; this hotspot is a
base workload-profile policy applied before root construction.

## Frozen profile

Use the following resolved workload profile in the rendered scenario spec:

```yaml
pressure:
  workload_mix: internet_platform
  workload_profile:
    name: internet-service-area-20-80
    hot_dimensions:
      - service_area
    hot_set_size: 0
    skew_percent: 80
    skew_function: hotset_uniform
    lineage_seed: 198
    hot_range_percent: 20
    hot_range_placement: middle
    hot_range_segments: []
    hot_density_ratio_target: 16
    derived_hot_pressure_percent: 80
```

The density target is `16`, because a 20% key range at 16x relative density
derives an 80% hot-traffic share. TiPOC rejects profiles that change either
share, add another hot dimension, use an unsupported selector, or omit the
positive lineage seed.

`hot_range_placement` may be `front`, `middle`, or `back`. The target is
selected from the ordered service-area IDs in immutable `UserSubjectPlan`
authority. When the prepared key count is not divisible by five, TiPOC
deterministically selects the nearest integer to 20% and records both the total
and selected key counts. For the 50G profile, 6,348 prepared keys produce a
1,270-key target (20.006%).

## Domain selection

The Internet scenario's existing `pressure.selected_businesses` remains the
single authority:

- `[ride]`, `[food]`, or `[mart]` runs one business only.
- Any ordered two-domain subset runs only those two production builders.
- `[ride, food, mart]` runs all domains.

No hotspot-specific domain switch exists. This preserves the same selection
contract used by canonical Internet pressure, Big Query, and Missing Index
cases.

## Required evidence

The compiled Internet scenario records profile name, `service_area`, 20%, 80%,
range placement, selector, lineage seed, and algorithm ID. The global business
order plan records:

- total and target service-area counts;
- exact ordered target service-area IDs and first/last bounds;
- total, hot, and non-hot eligible account counts;
- the user-subject authority digest and target digest.

Every normal-run domain receipt records one business-local hotspot section:

- `business`;
- `eligible_root_count`;
- `hot_target_root_count`;
- `non_hot_root_count`;
- `configured_hot_percent`;
- `observed_hot_basis_points`;
- target count/bounds, eligible-account partition, seed, algorithm, and digest.

Recovery and rerun cleanup publish no hotspot measurement. They may consume a
prior receipt only as durable recovery authority; they cannot claim a new 20/80
observation without constructing and admitting new roots.

## E2E interpretation

The receipt proves deterministic business-key selection, not physical TiKV
Region concentration. Formal E2E evidence must additionally map the selected
service-area keys to TiDB table handles or indexes and then use PD/TiKV metrics
to show the actual Region distribution during the measurement window. Do not
label the result "one hot Region" unless that independent mapping proves it.

A normal observation should be close to 8,000 basis points for each selected
domain. Small runs can vary because the 80% choice is deterministic sampling,
not a post-hoc forced count. Report the numerator, denominator, and sample size;
do not report only the percentage.

This SOP and the testcase matrix are configuration contracts, not live 50G
evidence and not an RU acceptance threshold.