3 common pitfalls of microservices integration—and how to avoid them

How to overcome the challenges of remote communication, asynchronicity, and transactions in microservices infrastructure

1 2 Page 2
Page 2 of 2

I talked a lot about retries. A common question is, what if I call a service twice by retries? This is a very good question!

First make sure you understand that you will have this problem with every form of remote communication! Whenever you communicate over a network, you cannot differentiate between three failure scenarios:

  • The request hasn’t reached the provider
  • The request has reached the provider, but it blew up during processing
  • The provider processed the request, but the response was lost
microservices client service Camunda

One possibility would be to ask the service provider if it already saw this request. But the more common approach is to use retrying and implement the service provider in a way that it allows for duplicate calls. This is simply easier to set up .

I see two easy ways of mastering idempotency:

  • Natural idempotency. Some methods can be executed as often as you want because they just flip some state. Example: confirmCustomer()
  • Business idempotency. Sometimes you have business identifiers that allow you to detect duplicate calls. Example: createCustomer(email)

If these approaches will not work, you will need to add your own idempotency handling:

  • Unique ID. You can generate a unique identifier and add it to the call. This way a duplicate call can be easily spotted if you store that ID on the service provider side. If you leverage a workflow engine you probably can let it do the heavy lifting (e.g. as Camunda allows for duplicate checks on keys during startup). Example: charge(transactionId, amount)
  • Request hash. If you use messaging you can do the same thing by storing hashes of your messages. You could again leverage the workflow engine for that, or you could use a database with built-in lease capabilities (like Redis).

Long story short: Take care of idempotency within your services. This will pay off big time. You can find a couple of code examples around the patterns I described here using BPMN and the open source Camunda engine.

In this article, I covered three common pitfalls I see customers stepping in when integrating microservices: underestimating the complexity of remote communication, ignoring the challenges of asynchronicity, and forgetting about business transactions.

Introducing capabilities to handle these situations with stateful patterns around retries, timeouts, and compensation activities can reduce the overall complexity of your microservices infrastructure and increase its resilience. It also helps to:

  • Encapsulate important failure handling and transaction behavior where it belongs: within the context of the service itself.
  • Reduce the effort of failure or timeout handling to a much smaller scope, reducing overall complexity.
  • Simplify the API of services, only handing out failures that really matter for clients.
  • Improve the client experience, where a client might be another service, an internal employee, or even the customer.

Using a lightweight workflow engine allows you to handle stateful patterns without investing a lot of effort or risking accidental complexity by applying homegrown solutions. The accompanying source code offers concrete examples.

Bernd Ruecker is the co-founder and developer advocate of Camunda. He is currently focused on creating new “big workflow” paradigms around distributed systems, microservices, domain-driven design, event-driven architecture, and reactive systems. Throughout his 15-plus years in software development, Bernd has implemented highly efficient and scalable core workflows at global companies including T-Mobile, Lufthansa, and Zalando. He has also co-created various open source workflow engines.

Bernd co-authored Real-Life BPMN, a popular book about workflow modeling and automation, now in its fifth edition and available in English, German and Spanish. Follow him on Medium at https://medium.com/@berndruecker or on Twitter at @berndruecker.

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.

1 2 Page 2
Page 2 of 2