Cool, congratulations! 🙂 I was ~unaware of Tarantool until you posted this, but it looks like a fascinating alternative to Redis & much more. As far as the integration with XT, I am excited by your roadmap on the readme: > ✓ Add tx-log > ❏ Add kv-store > ❏ Add document-store

I'm somewhat surprised nobody has implemented RESP-compatibility for Tarantool yet, to attract more attention from Redis users (or at least I can't find such a thing). This brief comparison between Redis and Tarantool was helpful for me as the main docs are huge https://stackoverflow.com/questions/67481042/when-to-redis-when-to-tarantool

Does this tx-log implementation already take into account the various WAL / clustering / synchronous transaction (etc.) configurations needed to provide HA & ACID durability for multiple XT nodes? Or are you only able to validate that once you have completed the other items further down in the roadmap (i.e. "Add an example of using a tarantool cartridge", and "Add an example of using a tarantool kubernetes operator (single node / cluster / with sharding")

Yes, I will be able to give more information after implementing the basic XTDB API and after developing the Tarantool cluster configuration using the tarantool-cartridge https://www.tarantool.io/en/doc/latest/getting_started/getting_started_cartridge/ In this solution I use the tarantool-cartridge java connector. Some information from the readme:

Java driver for Tarantool Cartridge for Tarantool versions 1.10+ based on the asynchronous Netty framework and official MessagePack serializer. Provides CRUD APIs for seamlessly working with standalone Tarantool servers and clusters managed by Tarantool Cartridge with sharding via vshard.