Plugin system for app with microservice architecture

Question

Long story short: I would like to create a plugin system for my microservice architectured app. so we can allow our customers to install their plugins. (something like a plugin system on wordpress|...)

Each plugin:

• Receives pre/post hooks for every operation from our microservices (e.g., productWillBeCreated(),productHasBeenCreated() hooks)
• It has access to an API to do some operations on our microservices.

My plugin system design: put the plugin(as a server) on another node/container/k8s pod and then call its methods that are listening to the hooks using RPC calls from our microservices.

Problem: How can we keep consistency while we allow the plugin to call multiple microservices in a hook? e.g., if our plugin calls two microservices to create two entities in one of its hooks, it can fail at the second call.

If it was a monolith app, we could allow them to put it in a DB transaction(single DB for the whole app), but when we have multiple microservices, we should think of Saga pattern or a two-phase commit, which I think none of them is an easy solution when we want to bring to a plugin system. I was thinking about the idempotent implementation for hook handlers or maybe an easy implementation of Saga pattern on plugins.

Do you have a good solution/trick for its consistency problem or another plugin system design that fits microservice architectured apps?

Thanks in advance ❤️

Answer 1

Introduce an extra level of indirection:

The API exposed to plugins should be one - and just one - service of its own and encapsulate all allowed operations and transactions for any plugin. When there's a two-phase commit necessary for certain operations, then the plugin API should hide that from the plugins.

As a bonus, this will allow you to provide a more stable API for the plugins of your customers (where you don't have the code under your control) whilst the "internal" API (where you have the code under your control) might change over time.

Answer 2

Depending on your specific requirements, a wrapper architecture might be an alternative. A customer-specific wrapper could filter and process specific requests while forwarding other requests unfiltered. So instead of implementing pre/post hooks a wrapper would just implement its own createProduct() handler which calls the underlying service's createProduct() handler and could modify parameters and results (and call other services) around this "forwarding" call.

One advantage of this approach that wrappers can be cleanly nested, while multiple plugins hooking onto the same events may require other mechanisms to ensure that their actions don't conflict.