Investigate moving tlog to redis

[scaleupcto]

Conceptually, the redis API seems to make more sense for the tlog. Each tripod store has it's own redis list, ordered by time. When saving, you push a new transaction to the list. When replaying, pop one off the top. Each transaction document can have a ttl. No more issues with having to reclaim disk space as with Mongo.

We would have to investigate how durable the write of data to disk is with redis and whether this is acceptable for the tlog usecase.

[junglebarry]

Might be worth approaching this with caution. From what I've read, the design goals of Redis may not align with what we'd like from a transactional store.

• https://aphyr.com/posts/283-jepsen-redis
• https://aphyr.com/posts/307-jepsen-redis-redux
• https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

[scaleupcto]

Well, that is true but really what the tlog is is a write-ahead log with strong sequencing, not a transactional style store. Perhaps something stream based is even better.