There are two ways of getting data into Metronome:
- Event ingestion via the
/ingestAPI endpoint or with our Segment integration.
- API requests for resource creation, such as
POSTing to create a customer or credit pool.
These two types of data are handled differently due to their nature and scale.
Event data is streamed to Metronome in bulk at high scale, making it impractical for the client to confirm receipt of individual datapoints. As such, the Metronome system is architected around the concept of unique
transaction_ids per event. Metronome guarantees that events with the same
transaction_id will not be double-ingested, allowing the client to safely send (and resend) events to Metronome, while ensuring each unique event is processed exactly once.
Separately, when creating or updating resources via the Metronome REST API, you often want to ensure a change is enacted while also avoiding the possibility of double writing. For this purpose Metronome supports sending an
Idempotency-Key header. If the
Idempotency-Key header is provided, and the request begins executing (it passed validation and doesn't conflict with another concurrent request), the results of the API call are persisted (even in the case of an HTTP 500 error), and returned for subsequent requests with the same key. The
idempotency-key is expected to be unique per request, and reusing an
idempotency-key for a request with different parameters will error with an HTTP 409 status code, preventing accidental reuse. This allows clients to safely retry requests without worrying about double writes.
The cache is periodically pruned but guarantees ≥ 24 hour protection.