suggestion/ We need these maps because of using single instance of VNSMetric for the entire RUM application. If we instead create a distinct one for each RUM view scope there will be no need for using hash maps, passing view ID all around and likely the purge() routine will be gone. Eventually it can simplify this implementation.

Considering data flow and the domain of this problem (individual view metric), do we gain anything by sharing the same VNSMetric instance with all view scopes?

you are totally right...I think there's nothing we can win here at least in this case. For the other metric we will have to share it so I am wondering if I should do it differently for this one ? What do you think ? It makes sense to remove the complexity though.

One of the other reasons I wanted to share it was to not have to instantiate this all the time but I guess the memory penalty is not that high. And we will win on one side (not having multiple instances) but loose on the other that I will have to keep these maps and purge them from time to time.

question/ Do we need a PriorityQueue()? At the end, all we're looking for is the eventTimestampInNanos of the last stopped resource which can be stored on single property. As long as we can assume that events arrive in order, the same can be achieved without using any data structures:

private var numberOfPendingResources: Int = 0
private var timestampOfLastStoppedResourceNs: Long?

fun resourceWasStarted() {
   numberOfPendingResources += 1
}

fun resourceWasStopped(eventTimestampInNanos: Long) {
   timestampOfLastStoppedResourceNs = eventTimestampInNanos
   numberOfPendingResources -= 1
}

you need a MaxHeap there (in Java that's a PriorityQueue) in order to make sure you have everything ordered as you cannot guarantee the resources are going to be stopped in the same order. So you need to make sure that the last one is the max. In the end you do not need that if you prefer to do the sort when you compute and pick the highest one. For me I prefer this because it is a bit more efficient.

Based on the RFC we need to provide a strategy with time interval and have default value to 100ms. We can either do this or just provide 2 strategies, one with a constant 100ms interval and the other with a configurable required interval in the constructor: StaticTimeIntervalBasedStrategy, CustomTimeIntervalBasedStrategy but I do think this kind of overkill. WDYT.

This is not the end of it, we can discuss a bit more about this if you want. There will be another strategy which will accept a configurable interface which will be the RequestValidator which is an interface. I did not expose yet this interface because this will be in another task. The reason why I like strategies is that they are exhaustive and also the client will be able to pick from a definite set. One strategy is based only on a time interval so the above definition doesn't match. The client will have to only define the timeInterval and that will be it he doesn't need to implement any interface. The default value is 100ms as this is defined in the RFC. I guess you will see it better once we add the other tasks also.