Vanilla Java

Apache Kafka is a common choice for inter-service communication. Kafka facilitates the parallel processing of messages and is a good choice for log aggregation. Kafka claims to be low latency, high throughput . However, is Kafka fast enough for many microservices applications in the cloud? When I wrote Chronicle Queue Open Source my aim was to develop a messaging framework with microsecond latencies, and banks around the world have adopted it for use in their latency-sensitive trading systems. In this article, I will describe how Kafka does not scale in terms of throughput as easily as Chronicle Queue for microservices applications. As a teaser, I will show you this chart showing that Chronicle Queue is around 750 times faster even for lower throughput. Visualising delay as a distance In order to illustrate the difference, let me start with an analogy. Light travels through optic fibre and copper at about two thirds the speed of light in a vacuum, so to appreciate very short de

Recently I published an article on using timestamps as unique identifiers , generated in a fraction of a microsecond. This article covers an implementation that supports distributed identifier generation directly. This specific implementation supports up to one billion new 64-bit identifiers every second only repeating after 520 years. They can also be printed as timestamps containing the wall clock to make it easier to read. Concurrent identifier generation in a distributed system Each host has a predefined, unique host identifier, or hostId . This TimeProvider assumes up to 100 hosts to produce different identifiers concurrently.  JVMs using the same hostId must be on the same physical machine using the same memory-mapped file, or you can give each JVM a different hostId A nano-second timestamp with a host identifier DistributedUniqueTimeProvider stores a host identifier in the lower two digits of the timestamp making it easier to read. The previous implementation used bit shifting