When metric events are being consumed (ingested), no matter the source, the component should determine a set of event records that need to be created, to apply this change. In most cases, this will be a simple addition, however, if any incoming event is in conflict in any way (usage already applied via another event), it will need to produce the necessary Events to allow tally to move in a forward direction only.

For example, if an event is received that appears to have already been tallied, but changes the measured value for that hour, 2 events would be created to resolve this conflict. First, an event should be created to deduct the old usage from an account during that hour, and then another event created to apply the new value. When hourly tally runs, this would result in the tallied measurement being reduced based on the already applied event, and the new value applied.

References:

• https://docs.google.com/document/d/1SDGIOQMP4AtE0pIqrltLH_qVi0zWwJAp68v3ltodtVo
• https://miro.com/app/board/uXjVMj0v_G8=/?share_link_id=382208098119

Steps:

• During event message consumption, determine if an incoming event is in conflict by fetching events matching the key (org_id, event_type, event_source, instance_id, timestamp)
  • If in conflict:
    • When measurement values are equal, do nothing.
    • When measurement values are different,
      • Create an Event deducting the existing value (negative quantity)
      • Create an Event adding the new value.
  • No conflict:
    • Create an Event with the new value.
• Update the internal saveEvents API in the InternalTallyResource to process the incoming Event JSON via the same logic as incoming event messages.

AC:

• Event ingestion should create additional events when adjustments are required.