In Micrometer, the same counter can be registered from several places without creating duplicate series, a counter on a step-based export registry can read as zero moments after you incremented it, and an export that fails can lose a whole interval. Explain the registry mechanics behind all three: how Micrometer decides that two registrations refer to the same meter, what accumulate-and-reset means for step meters and which interval a step meter's reported value refers to, and what a step-based registry does when a publish fails.

## What a registry actually stores A `MeterRegistry` is a map from meter identity to meter state, plus a strategy for getting that state to a backend. Everything surprising about Micrometer at runtime comes from one of three properties of that map: how identity is computed, how the stored value moves through time on step-based registries, and what happens on the way out. ## Identity: registration is idempotent by `Meter.Id` Every meter is keyed by a `Meter.Id`, which is the meter **name** plus its **tag set**. Tags are normalised — sorted and de-duplicated by key — before the id is formed, so `tags("a","1","b","2")` and `tags("b","2","a","1")` are the *same* meter, and tag order can never accidentally create two series. The consequence is that registration is **idempotent**: asking the registry for a counter that already exists returns the existing instance instead of creating a second one. This is what makes it safe for several components — your code, a library, an auto-instrumentation agent — to register the same meter independently, and it is why the builder-then-register call on a warm path is correct rather than a leak. (Caching the returned handle in a field is still the conventional style; it avoids the lookup, not a correctness problem.) Two edges follow from the same rule. First, if a meter with that id already exists but is a **different meter type**, the registry refuses the registration with an error rather than creating a parallel series — one name cannot be both a counter and a timer. Second, for meters that are bound to an object at registration time, re-registering the same id does **not** rebind: the registry hands back the meter that is already there and quietly ignores the new state object you passed. A second registration pointing at a fresh object therefore keeps reporting the first one, which is a classic "my gauge is stuck" bug. Duplicate series in a backend are almost never caused by repeated registration; they are caused by *different* tag sets, i.e. different ids. ## Step meters: accumulate, roll over, reset Export registries that push data to a backend are **step-based**. A step counter does not hold a lifetime total. It accumulates recordings into the current interval, and at each step boundary the current interval becomes the previous interval and the accumulator resets to zero. The part that catches people out is which number is visible: **a step meter reports the last completed interval**. Increment a step counter and read its count immediately and you see the previous interval's value — often zero on a freshly started process. Nothing was lost; the in-progress interval is simply not observable until it closes. Cumulative registries behave differently: an in-memory or scrape-rendered registry can carry a monotonically increasing total, so the same test written against a cumulative registry passes and against a step registry fails. ## The publish schedule *is* the step A push/step registry schedules its own publish, and that schedule is derived from the configured step interval — they are the same value by construction, and there is no second "publish every N seconds" knob to set against it. So the misconfiguration worth teaching is **not** two intervals drifting apart. It is: - a step that **disagrees with the backend's own aggregation window**, so intervals land unevenly inside the backend's buckets and rates look spiky or diluted; and - **different steps across services**, which makes their rates non-comparable and any cross-service dashboard subtly wrong. Pick one step for the fleet, and pick it to match what the backend aggregates on. ## Export is best-effort A publish is a fire-and-forget attempt. Failures are caught and logged so the scheduler survives, and the batch is **dropped** — there is no durable queue, no retry of the previous interval on the next tick. Because a step meter has already reset, that interval is gone permanently: you get a hole, not a delayed spike. Treat the exporter's own failure counters and logs as first-class signals, and remember that a clean shutdown gives the registry a chance to flush a final publish while a hard kill does not. ## Testing against these rules `SimpleMeterRegistry` is the in-memory registry with no export at all — the right tool for unit tests. It counts cumulatively by default, so counts do not vanish under you mid-test. Combine it with the library's mock clock when you specifically want to exercise step behaviour: advance the clock past a step boundary and then assert, which is the only honest way to test roll-over. Reading values back through the registry's search API also surfaces identity mistakes immediately — a lookup that fails to find a meter with the tags you expected is usually telling you that a tag typo produced a different `Meter.Id`.