Probabilistic Behaviour can Sometimes Replace State at Scale

Last updated: 28 Aug 2021

Table of Contents

Intro

Sometimes we need to keep track of actions in a system.

This usually requires a database or some other record (such as text files, csv, etc) to keep track of the state of said system.

For example:

You want to send clients emails about new offers every month, starting on the day they joined your website. But you need to check how recently they got an email so that you don't saturate them with too much information.

You can sometimes drop that requirement if you can afford to have some inaccuracies and have accurate behaviour on average:

For example:

Instead of scheduling an email to be sent to each customer on a fixed schedule depending on when they joined your website, you can run some code every day that has 1/30 chance of sending the email.

On average, every customer will get an email roughly once per month, but the logic is now much simpler.

You completely remove state from your logic, making it simpler and less error-prone, no need to create a database, etc;
No problem if you lose data, making your system much more resilient and easy to restart on demand;
Much easier to scale (splitting behaviour into several independent machines / nodes), because you don't have a single bottleneck (databases with atomic reads/writes)
Whenever you're interacting with humans, the random effect will add some spice to your interaction
- Because it's not entirely predictable when actions are taken - this delivers extra impact when they do happen
- Just think how boring it would be to get sent an email at exactly same day/time every week. Eventually you just start ignoring it.

Well, there are obvious cases when you cannot do that, for instance:

You need synchronous, stateful logic when settling purchases/sales if you run a bank.
Anything else that depends on ordering can probably not take advantage of this type of stochastic behaviour: (think chat messages, games, videos, etc.)