Rationale

The design of Fink is driven by three pillars:

• Simplicity: a broker should be simple enough to be used by a majority of scientists and maintained in real-time. This means the exposed API must be easily understood by anyone, and the code base should be as small as possible to allow easy maintenance and upgrade.
• Scalability: broker's behaviour should be the same regardless the amount of incoming data. This implies the technology used for this is scalable.
• Flexibility: the broker structure should allow for easy extension. As data will come, new features will be added, and the broker should be able to incorporate those smoothly. In addition, the broker should be able to connect to a large numbers of external tools and frameworks to maximize its scientific production without redeveloping tools.

We want Fink to be able to filter, aggregate, enrich, consume incoming Kafka topics (stream of alerts) or otherwise transform into new topics for further consumption or follow-up processing. Following LSST LDM-612, Fink's ultimate objectives are (no specific order):

• redistributing alert packets
• filtering alerts
• cross-correlating alerts with other static catalogs or alert stream
• classifying events scientifically
• providing user interfaces to the data
• coordinating scientific activity among collaborators
• triggering followup observing
• for users with appropriate data rights, facilitating followup queries and/or user-generated processing within the corresponding Data Access Center
• managing annotation & citation as followup observations are made
• collecting classification and other information gathered by the scientific community