While the goal of the whole Drools platform is to provide a seamless environment for users to model business behavior using rules, processes and events, it is a misconception to say that it is all executed on RETE. Besides implementing several optimizations on top of the classic RETE algorithm (as designed by Dr. Forgy back in the 70's), Drools has specific algorithms to which it delegates processing of specific use cases/features (read some fusion and flow features). 

    Regarding your question, entry-points are partitions on the RETE network that allow for parts of it to be evaluated concurrently, besides creating separate "name spaces" for facts (scopes if you will). So it does help on reducing the overall load of the matching algorithm. Although, rules are still fired sequentially as to ensure consistency of the working memory. 

    Regarding use cases, we have customers that use 24x7 stateful sessions, keeping over 1M facts in memory constantly, with new facts coming into the session and facts expiring from the session all the time. The throughput of such use cases is obviously dependent on the percentage of facts/rules matchings, so it is hard to foresee what you will achieve on your use case without knowing in detail your rules.

    Although, the chosen architecture for your kbase and sessions will obviously have a high impact on the performance metrics you will achieve. Since you mentioned that in your use case every single fact will match and cause rules to fire, and the actions involve heavy operations like database access, I would recommend looking into an "agent" architecture, where you partition your knowledge base into several kbases with related rules. The kbases will operate on the atomic (or "raw") events and create the composite events that you can feed into entry points of sessions of subsequent kbases, effectively increasing the overall system throughput and simplifying the maintenance of each agent's kbase in particular.

    If you are used to CEP nomenclature, you know that the above is a simplified description of an EPN. 

    Finally, you asked about the difference between regular facts and events, and basically all events are facts with special "properties". These properties allow the engine to do some fancy stuff with them, like the use of sliding windows or event lifecycle management (i.e., automatically expiring events). Although, there is nothing wrong in modeling events like regular facts if that best fits your design.

    Hope the above helps,

        Edson 




--
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com