It depends. Is the counter really a “metric” or is that tracking part of the service you’re providing? If it’s the first one then telemetry is imo the way to go. If not than your solution seems like the appropriate one.
Telemetry is way more than just means of updating a number in some database. It’s a generalized and structured way of publishing events in your application code, so you can listen to those in places external to your core business logic for (pre)-processing, aggregation and eventual forwarding to things like persistent storages, dashboards and similar tools for inspecting the inner workings of your project.
The pubsub architecture allows for quite lean code needing to be added to your business logic for instrumentation, compared to doing everything mentioned above in place, which can sometimes even make the business logic non-obvious because of all the additional stuff going on. Also what you actually listen on is not scattered across your whole codebase.
The other benefit is that given telemetry becomes more and more the standard in elixir libraries you can use one tool to not only instrument your code, but also to listen to events published by the libraries you’re using.
Another benefit of also letting people create their own listeners: It’s quite flexible to allow for situations like pushing metrics to a not yet natively supported service/db, allow for different sets of metrics to be sent to different endpoints.
All that flexibility comes for the price of a bit more upfront cost in implementation. It’s not just a single line Repo.update.
