3 ms·
I don't know much about RabbitMQ, but with XTDB, it basically runs in the application already (akin to sqlite) while using another DB engine for the actual stor
by capableweb 4y ago
I don't know much about RabbitMQ, but with XTDB, it basically runs in the application already (akin to sqlite) while using another DB engine for the actual storage. So with XTDB you can store things in memory, on disk via rocksdb, or JDBC connection (whatever that supports, MySQL, PostgreSQL and so on)
- lipsyclouds 4y agohello! the author here! the primary reason for going with this architecture is to make it scale well with off the shelf production ready tooling. RabbitMQ was chosen to provide a scalable durable queue for backpressure support and load balancing across runners, error handling etc. it adds onto the infra weight a bit but seems to be a simpler choice to program against and use libraries. The reasons for XTDB are mainly 2: it provides a temporal immutable store, hence the whole state of the CI system can immutably evolve like a git repo hence the whole thing can be inspected at a previous time. Bob treats time as a first class thing and not just build logs but you should be able to see the whole cluster at a past time and debug it fully as all of the state is the DB. The second reason is like @capableweb said, it decouples storage from compute so that we can have a pluggable storage and not a central point of compute.