Niklas

Idea from @VithikaS: If tables like `COMPONENT` and `PROJECT` had `CREATED_AT`, `UPDATED_AT` etc. columns, it would be possible to build indexes incrementally. This would make (re-)indexing solely via database queries...

Leaning onto [Full Text Search](https://www.postgresql.org/docs/current/textsearch.html) capabilities of the database we're already using might be preferable for multiple reasons: * Search results are always consistent with what's in the database *...

For a short-term solution, we decided to drop Lucene entirely: #661

The problem is also documented here: https://medium.com/@andy.bryant/kafka-streams-work-allocation-4f31c24753cc

Using [Smallrye reactive messaging](https://quarkus.io/guides/kafka) would linder this pain, but introduce others. With SRM, consumer threads can be scaled independently. Major downsides are that we'd loose the convenience of Kafka-backed state...

Wondering how much this actually matters considering that a "completed" analysis would require results from all scanners anyway. Makes it questionable whether OSS Index being significantly faster than Snyk makes...

SRM behaves in very unintuitive ways: * Consuming from multiple partitions of a topic in parallel is supported, unless [`@Blocking`](https://quarkus.io/guides/kafka#blocking-processing) is used * `@Blocking` is required for synchronous things, e.g....

Relates to #215

parallel-consumer was adopted in API server and notification-publisher.

It would be good to have the use-case behind this enhancement documented. In addition to the use case itself, as @sahibamittal mentioned, a list of pros and cons should be...