3 ms·
The use of XTDB and RabbitMQ is annoyingly overcomplicated. Why have a central database? Why not use a simpler more standard storage mechanism, or just pluggabl
by throwawaaarrgh 4y ago
The use of XTDB and RabbitMQ is annoyingly overcomplicated. Why have a central database? Why not use a simpler more standard storage mechanism, or just pluggable storage for each component? Why not just use HTTP calls to static nodes instead of RabbitMQ?
- capableweb 4y agoI 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.