Drools documentation

Ideas you will meet

Event Driven Architecture

Loosely coupled services reacting to events.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

• Storage, Queues and Real-time · 11 minA rule engine and trigger frameworkMatch product events against versioned rules and run actions safely: rule shape, evaluation, idempotent actions, rate limits, testing and audit.Read hereClose

  What it is

  A rule engine (or trigger framework) lets you say "when this happens and if these conditions hold, do that", without writing a new code path each time. Examples: send a welcome message when a user signs up, flag an order when the amount is unusual, award a badge after five purchases.

  Product and operations teams want to change these often, so the rules should be data that a service evaluates, not code that must be redeployed.

  100%

  Figure SDA-SQR-04-1 · From event to action · © forcsguy.com

  What a rule contains

  • Identity and version: id, version, owner, enabled. Never edit in place; publish a new version so you can audit and roll back.
  • Trigger: an event type, or a schedule for time-based rules.
  • Condition: a structured tree such as all of [ plan = free, country in (IN, US), purchases >= 5 ], or a restricted expression language. Avoid arbitrary code.
  • Action: a named action with parameters (send_email(template_id), add_badge(name)).
  • Controls: cooldown, per-user and global limits, start and end dates.

  Evaluating efficiently

  • Index rules by event type so an event only looks at its few candidate rules, not all rules.
  • Fetch extra user data (attributes, counters) lazily and cache it for the duration of the event, as lookups usually cost more than the comparisons.
  • For time-based conditions ("14 days without login") run a scheduled scan or use delayed events, rather than polling every user.
  • Evaluate in workers that are partitioned by user, so state like cooldowns and counters for one user is handled in order.

  Safe, idempotent actions

  Events can be delivered more than once and workers retry. Guard every action with an idempotency key, for example rule:version:user:window, stored in a unique-key table or key-value store before (or together with) performing the action.

  100%

  Figure SDA-SQR-04-2 · Idempotent action execution · © forcsguy.com

  Operating a rule engine

  • Validation at publish time: reject unknown fields, huge conditions and loops.
  • Dry run and replay: run a new rule against recent historical events and report how many it would fire, before enabling it.
  • Kill switch per rule and globally, since a bad rule can email a million users.
  • Limits: maximum rule size, evaluation time and actions per event.
  • Audit: who changed which version and when; for each event, which rules fired or were skipped and why.
  • Know the cost: a large pile of rules becomes software nobody understands. Fowler's advice is to prefer plain code for logic that rarely changes, and use rules for what truly varies.

  Real-world reading

  Related reading

  • Rules Engine (Martin Fowler)Martin Fowler · martinfowler.comBlogs
  • Drools documentationDrools community · Drools (KIE)Documentation
  • What is SELECT SKIP LOCKED for in PostgreSQL?2ndQuadrant · 2ndQuadrant (EDB)Blogs
  • Scaling Slack's Job QueueSlack Engineering · SlackCase Studies

  Open this lesson with its quiz and exercise