User Journey: Keep the market data sources running

"I want every market data source this installation runs to be up, and to know the moment one goes quiet." The journey is done when each source is shown with its kind, its adapter state, the ids it serves, the ids it rejects and when it last ticked, and the operator has brought back what needed it.

The actor is the system administrator: an account with the SuperAdmin role, acting from the system tenant in system administration mode, as the Operations journeys group sets out. Reading needs marketdata::sources:read. The same screen serves live and simulated sources and shows the kind as a badge. See No code path may behave differently because a source is simulated.

The trigger is a service restart, a source the desk says is silent, a new adapter to bring up, or a routine check. The journey starts at Operations, then Market data sources, and ends when the operator leaves the screen.

1. List the sources. The person opens Operations and then Market data sources. The system lists every source: name, provider, kind badge, adapter state, heartbeat age, the count of ids in demand, the count rejected, the last tick and the drop count of the last hour.
2. Read one source. The person selects a row. The system shows the source's fields, its rate card, the parties routed to it, and the history of its state. See The adapter lifecycle.
3. Read the demand. The person opens the demand set. The system lists the ids the source serves, and the ids it rejected with the reason. See Demand drives what an adapter publishes.
4. Read the quality drops. The system shows drops by reason for the source: unmapped, not a number, out of range, stale, out of order. See Quality checks run between mapping and storage and ignore the source kind.
5. See a source that has gone quiet. A source is quiet when it is serving and has not ticked inside the interval its demand implies, or when its adapter is stale. The person sorts by last tick.
6. Bring a source back. For a stale adapter, the person reads the adapter's log and restarts the adapter service. The service sends the demand set again when the heartbeat returns. For a simulated source the person can also start and stop single generators from the simulator area; the demand set does the rest.
7. Read what a party takes. The person opens the parties routed to a source and follows the link to the party's subscription.
8. Leave. The person goes back to the Operations area.

A quiet source has stopped delivering, whatever its adapter says. The checks go in this order.

1. Heartbeat. A missed heartbeat makes the adapter stale. The service keeps the routes and waits.
2. Demand. An adapter that serves an empty demand set has nothing to send. Check that a party routes to the source.
3. Rejected ids. An id the adapter rejects with unknown_id or not_entitled delivers nothing. Check the catalogue and the vendor entitlement.
4. Mapping. Ticks that arrive but are dropped as unmapped show in the quality counters. Check the mapping of the provider.
5. Generators. For a simulated source, a generator that failed to start rejects its ids. The reason is in the reply. Two generators for one vendor instrument conflict, and the runner names the holder.

An adapter restart needs no person to restore the state. The adapter announces again, the service sends the demand set, and delivery resumes.

One screen of the table, a detail panel, and the demand and drops views. The wireframe is still to be drawn.

• Manage market data subscriptions — what a party takes and from which source.
• Offer a synthetic collection — how a simulator author prepares the generators.

• The adapter lifecycle
• Demand drives what an adapter publishes
• Quality checks run between mapping and storage and ignore the source kind
• A live and a simulated source differ only inside the adapter
• Market Data Architecture