Questions about the arch decisions

[kanadaj]

So I have a few questions regarding the decisions that went into Featbit and I'm genuinely curious to know why things were set up the way they were:

1. Why MongoDB instead of Postgres or Postgres JSONB? I've always found MongoDB to be incredibly unstable at scale, with frequent segfaults. Is there something about MongoDB in particular that caused it to be the preferred solution?
2. Why a Python service for the analytics server when everything else is C#? Was there a particular library or feature to drive this decision?
3. Why run Kafka without KRaft? It's been marked Production Ready back in October.
4. Any particular reason why the Kubernetes manifests define Pods instead of StatefulSets?

[cosmos-explorer]

Hi @kanadaj , thank you for your interest to us. These are very good questions, here is our answers:

Why MongoDB instead of Postgres or Postgres JSONB? I've always found MongoDB to be incredibly unstable at scale, with frequent segfaults. Is there something about MongoDB in particular that caused it to be the preferred solution?

We opted for MongoDB in FeatBit because we had prior experience using it for other projects, which made us familiar with its features and functionalities. At the time of our decision, MongoDB met all the specific requirements we had for our project. However, we acknowledge that Postgres could be a viable alternative, even though we haven't used it before. We did discuss the possibility of supporting multiple databases and concluded that it would be beneficial. Unfortunately, due to limited resources, we haven't been able to implement it. We always encourage contributions from the community, so if you're interested and have the time, we would greatly appreciate a pull request to add Postgres support.

Why a Python service for the analytics server when everything else is C#? Was there a particular library or feature to drive this decision?

The decision to use Python for the analytics server aligns with common practices in the field of data analytics. Python offers a powerful toolbox that greatly aids in data analysis tasks. FeatBit is built upon a microservice infrastructure where each component is loosely decoupled, allowing us to leverage the most suitable tools for each service. Hence, Python was a natural choice for the analytics server, as it provides an extensive range of libraries and features specifically designed for efficient data analysis.

Why run Kafka without KRaft? It's been marked Production Ready back in October.

When we first introduced Kafka into our setup, KRaft had not yet been marked as production ready. However, we do recognize the benefits of KRaft and will consider removing the dependency on ZooKeeper. Thank you for bringing this up!

Any particular reason why the Kubernetes manifests define Pods instead of StatefulSets?

The Kubernetes manifests provided are community-based and should be considered as references that can be modified to suit your specific enterprise needs. While the current manifests define Pods instead of StatefulSets, it's essential to adapt them according to your requirements and the characteristics of your workload. We have recently open-sourced a Helm chart solution, which you can explore in our repository here.

[cosmic-flood]

@kanadaj

Latest news:

Why MongoDB instead of Postgres or Postgres JSONB

FerretDB has officially created an issue to achieve compatibility with FeatBit. This allows companies that don't use MongoDB (but use PG only) to easily integrate with FeatBit. FerretDB/FerretDB#3202

Why run Kafka without KRaft?

We're switching from Zookeeper to KRaft. #476