2

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 ❤️

3
  • 3
    I hate to be harsh, but why did you settle on a microservices architecture? It seems a contradiction in terms with your requirement for a plug-in system. Dec 5, 2022 at 11:59
  • 1
    @BartvanIngenSchenau, short answer: because of the project scale. We had a lot of developers that were working on a monolith project, many merge conflicts, and also we were slow in releasing new features with a lot of headaches about breaking another part of the app if we didn't write a good test for a specific situation. I agree that we shouldn't make things complicated when don't need to it but I think having a microservice-architectured app with a plugin-in system is not a contradiction :)
    – Mehran Prs
    Dec 5, 2022 at 12:22
  • @MehranPrs Sorry to say this, but none of those issues have anything to do with being a monolith - just with being a poor codebase. I'm working with a massive monolith project, too, and a merge conflict that's more complex than poking a couple lines is a incredibly rare occurrence - and that's for a quite sizeable team, even. Going with Micros won't solve any of that - breaking chances can, and will, creep in anyway if your process isn't sharpened enough. The only difference is that microservices for you is that micros are a pain in the a** to debug.
    – T. Sar
    Dec 6, 2022 at 20:33

2 Answers 2

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.