Some Thoughts on Rules Engines

February 21, 2021

Spend enough time working with domain experts on a problem and someone is bound to say "we should build a rules engine to solve this problem." Often this comes along with the goal of letting domain experts express rules themselves rather than having to evolve engineers. However, once you start to dig into this problem you'll discover that "rules engine" can mean many different things to many different people.

I've seen this problem a few times over the past couple of years, and I've come to think it's useful to break down your rules engine across a few important axes. Doing this will allow you to have clear discussions on what problems you need to solve and what you need to build to solve them.

The questions

All of these taken together form a set of constraints for your rules engine. If you want to express arbitrary logic over arbitrary data, well then you're probably doing to need to write a business readable DSL or use something like drools. If you can simplify across some dimension, you can probably save yourself some work .

Looking at this in practice

Let's think about how all this works in practice by using a few examples.

Radar from Stripe

Stripe's Radar product has a rules engine which allows merchants to configure how they should handle charges. It answers the above questions in the following ways:

This approach constrains users across almost every dimension, but the resulting rules engine is simple enough that almost anyone can use it.

FXL From Facebook

At the other end of the spectrum is FXL, a language that Facebook developed for fighting spam. It has slightly different answers to these questions.

FXL's rules engine gives users more power at the expense of some complexity. The rules are actual code rather than fancy configuration. This creates spam fighting superpowers at the price of it being harder for non-engineers to interact with write.

SQL-Based Rules Engines

Another common pattern is the SQL-based rules engine, which has an example here. The general idea of these is often "our domain-experts already understand SQL, so let's allow them to just write their rules in a language they know." Again, this can fit into our framework.

These approaches fit somewhere in between the two approaches above. They seem useful when you want to return a simple classification result, but it may get more challenging if you want to take more complex actions.

Using the framework

I'm not totally sure exactly how to use this framework yet, but it has been useful for me to ask these questions whenever someone says "we need a rules engine." I hypothesize that if you want to keep the expression language simple, you'll need to invest more engineering-time to provide curated data to your rules engine and limit what it can do.

I also imagine that these approaches can be mixed-and-matched for maximum effectiveness. For example, you could have a rules engine which is based on a business readable DSL, and provide some tooling for non-engineers to create for common use-cases. This allows for iteration speed in the common case without sacrificing power when you really need something complex.

Discussion, links, and tweets

Hey! Thanks for reading! If you like what you read and want more, you can follow me on Twitter.