You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Millisecond is eternity in microservice world. More than a request duration if one builds something "micro". And for better or worse many people do. (and some other folks have just really fast machines and network)
The text was updated successfully, but these errors were encountered:
@jendap: That's a fair point. Part of the reason we picked millis has to do with the granularity of most downstream systems processing this data and their implementation details as well as the cost of higher resolution timers. Many systems that act on this data don't understand micros or nanos, so we'd lose granularity anyway. The issue around "cost" has to do with the size and code complexity to handle timestamps at those granularities, especially in languages that don't support unsigned types (e.g. JVM languages). That means those languages need to represent time in complex types. I might also challenge the assertion that microservices mean finer grained timing is required. All of the normal latency mechanics (https://gist.github.com/jboner/2841832) still apply to those services just as any others and we're not really targeting profiler-level timing.
I'm open to discussion on this, but I wanted to capture why we choose millis initially. Thanks!
The timestamp is already a "long". Signed integer being a problem? In year 2262 for nanoseconds - 2^63 / 10^2 / 3600 / 24 /365 ~= 292 years. Later for microseconds.
In order for anybody care in 2262 it has to be successful today. Today people are doing microservices, servless and / or async multithreaded stuff (on multicore cpus). People will not be happy once they get reordered (like in partitioned kafka topic).
Millisecond is eternity in microservice world. More than a request duration if one builds something "micro". And for better or worse many people do. (and some other folks have just really fast machines and network)
The text was updated successfully, but these errors were encountered: