Based on the aforementioned requirements, let us highlight some technical choices.
Some Reasons for choosing PostgreSQL as persistence layer for the Events:
Both technical requirements are trivial when choosing a RDBMS, due to its ACID nature and the availability of Sequences.
Monitoring, Alerting, Backup, Point in time recovery, Authentication / Authorization, read-replication, fail-over … All of those are properties of a good RDBMS and it is hard to find more mature solutions than the ones we can find there.
While Document datastores like MongoDB certainly have more to offer here, PostgreSQL is surprisingly good with JSON. FactCast uses GIN Indexes on JSONB Columns in order to find matching Facts for subscriptions easily.
With LISTEN and NOTIFY PostgreSQL makes the transition from a passive Data-store to a reactive one, that can be used to guarantee low latency pushes of new Facts down to subscribers, irrelevant at which instance of FactCast the write has happened, without the need of any further message-bus/topic/whatever.
A solved problem, that might help you with more than moderate traffic. While we would rather consider partitioning your Facts, in the first place, it might be a welcome ‘last resort’ when you have lots and lots of subscribers.
With AWS RDS for instance, it is rather trivial to setup and operate a PostgreSQL that satisfies the above needs. It is unlikely to find a respectable cloud platform without postgresql.
When it comes to raw performance, REST might not always be the best option. In order to offer a more compact transport, but yet stay platform neutral, FactCast also has a GRPC API. GRPC has a lot of implementations in languages like:
[
GRPC.io ](http://www.grpc.io/)
Spring Boot is a simple Framework to quickly spin up Java Servers. The FactCast Server is implemented using Spring Boot as a container.
In order to make it easy to use the GRPC Client from java, the factcast-client-grpc module depends on Spring as well. This dependency is not exactly tight, so if there is a good reason to, you might want to implement a GRPC CLient free of Spring dependencies. If so, let us know.