The shared component could help solve multiple scenarios:

— Eliminating duplicates —

— Multi cluster —

— Conversation tracking —

— Kube API —

FLPs flood kubeapi to get their cache up to date, especially on startup

We should PoC around a single component (at least with less replicas than FLPs) querying the cache from kube API and sharing it to FLPs

FLPs will still need to hold their own cache to avoid network queries between these components

Pros:

• no more api flood
• no more duplicates to manage on query sides (console plugin, prometheus, CLI)
• improved storage size
• improved conversation tracking

Cons:

• the total memory consumption will increase by the number of cache replicas
• a delay can appear between api / cache / flps
• if cache goes down, enrichement will be lost

Original discussion:

https://redhat-internal.slack.com/archives/C03PUMXPZGQ/p1691748982977429?thread_ts=1691477284.084449&cid=C03PUMXPZGQ 

Also, that shared component could hold more info in future to share conversation ids, help identify duplicates etc