Github user cestella commented on the issue: https://github.com/apache/metron/pull/940 The current architecture is described  In short, for each message each splitter will * inspect the configs for the sensor * For each sensor, extract the fields required for enrichment and send them to the appropriate enrichment bolt (e.g. hbase, geo, stellar) * If one enrichment enriches k fields, then k messages will be sent to the enrichment bolt * In the case of stellar, each stellar subgroup will be a separate message * the original message is sent directly to the join bolt * The enrichment bolts do the enrichment and send the additional fields and values to the original message * The join bolt will asynchronously collect the subresults and join them with the original message * The join bolt has a LRU cache to hold subresults until all results arrive * Tuning performance involves tuning this cache (max size and time until eviction) * Tuning this can be complex because it has to be large enough to handle spikes in traffic
---