These count maps are using a string which doesn't provide much type information, when they are actually keyed by sourceID, destinationID, sourceJobRunID, eventName, eventType.
A comparable struct key would would be much more appropriate, we could drop the strings.Join allocation for every event, and remove the split:

type metricCountKey struct {
	sourceID, destinationID, sourceJobRunID, eventName, eventType string
}

inCountMap and inCountMetadataMap always share the same key, so they could become a single map[metricCountKey]*metricCount{count int64; metadata MetricMetadata}. Failed and filtered have no metadata map, so they can stay map[metricCountKey]int64. Can you please create a followup ticket for this?

Agreed, a comparable key is the right shape. Tracked as PIPE-3466 (https://linear.app/rudderstack/issue/PIPE-3466): introduce metricCountKey{sourceID, destinationID, sourceJobRunID, eventName, eventType}, merge inCountMap and inCountMetadataMap into one map[metricCountKey]*metricCount, keep failed and filtered as map[metricCountKey]int64, and drop the strings.Join / strings.Split on the hot path.

Keeping it out of this PR on purpose: the key is built and split in the existing code and flows through updateMetricMaps, getTransformationMetrics, getNonSuccessfulMetrics and getDiffMetrics, so the change touches every call site including the user_transformer one. Planned as a standalone PR against master once this set has merged.