Track new storage, cache and audit implementations

[lucasoares]

As Deckard continues to evolve, we aim to explore new storage and cache implementations to enhance its capabilities and provide increased flexibility to our users.

Currently, we have the following production-ready implementations:

• Cache:
  • Redis
• Storage:
  • MongoDB
• Audit:
  • ElasticSearch

Our focus is on finding storage and cache solutions that can adapt to various user environments and seamlessly integrate with Deckard's existing architecture. It is crucial to evaluate options that can efficiently handle growing workloads, scale accordingly, and ensure optimal performance and compatibility with diverse deployment scenarios.

To begin, we will prioritize the creation of new storage implementations as they are relatively straightforward to implement. It is worth saying that Deckard's architecture heavily relies on Redis as the caching mechanism, making it a lower priority for developing a new cache implementation due to its widespread usage and complexity.

For the audit system, we may provide a new implementation soon integrating with any messaging system (like Kafka) which would allow our users to send audit data to anywhere they want.

We will use this issue to brainstorm and discuss potential storage, cache and implementations. Feel free to share your ideas, suggestions, or any relevant information that can help us identify and evaluate new options.

[lucasoares]

Suggestion: The storage implementation is much simpler than caching implementation, we could use GORM or anything like it, since it already has support for [MySQL, PostgreSQL, SQLite, SQL Server, TiDB, ClickHouse, etc)

@andreminelli also suggested we should create a documentation about all data models and about each one of Deckard's components with more details since the current one contains almost nothing.