Add a meters relationship to entitlements

[ezekg]

This would allow a license to have many meters/consumables, each metering an action.

[ezekg]

Meter by entitlement? E.g. a license has many meters/consumables through entitlements.

[ezekg]

Should be able to meter by "use count" as well as by aggregate "use time." These would both be the same, backed by a number, but just consumed and displayed differently.

[ezekg]

Should be able to meter by "uniques", via a unique ID. For example, metering by unique client pings per-month.

POST /uses
{
  "data": [{
    "type": "use",
    "id": "some-client-id",
    "attributes": {
      "created": "<timestamp>",
      "amount": 1
    },
    "relationships": {
      "meter": {
        "data": { "type": "meter", "id": "..." }
      }
    }
  }]
}

[ezekg]

Add consumption strategy to a meter. Options: DECREMENT, INCREMENT.

[ezekg]

Maybe we should set this up similarly to entitlements, allowing meters to be attached via the policy or the license.

class Meter
  belongs_to :account
  has_many :policy_meters
  has_many :license_meters

  attribute :consumption_strategy,
    options: %w[INCREMENT DECREMENT]
end

class PolicyMeter
  belongs_to :policy
  belongs_to :meter
end

class LicenseMeter
  belongs_to :license
  belongs_to :meter
end

class LicenseUse
  belongs_to :policy_meter,  optional: true
  belongs_to :license_meter, optional: true
  belongs_to :license

  validates :meter?,
    message: 'meter is missing'

  # Used for tracking when a use occurred
  has_timestamps

  def meter  = policy_meter.presence || license_meter
  def meter? = meter.present?
end

[ezekg]

My big fear here is volume. This may require us to offload to a third-party, or use a different DB such as Clickhouse or Timescale.

Performance is already hard enough for request/event logs.

This should be easier now with #948.

[ezekg]

Should we add support for atomic/sync/async consumptions? E.g. for some meters, it may be okay for an overage to occur, or maybe there's no concept of an overage, and in that case, async would be fine. But other meters, like a decrementing one, going below zero is likely not something a user wants, and in that case, a sync meter would work better. Sync meters would need to have a low or immediately timeout on contention so that we don't queue too many requests unnecessarily.

[ezekg]

Should meters also have an overage strategy like policies? Sync would obviously check for overages inline, and async will check against the latest persisted value which may allow a bit of divergence i.r.t. actual overage vs expected overage.