Skip to main content

Align Synchronicity to Business Flows

Context​

Microservices are used or are being adopted. A domain analysis results in business flows across subdomains. These business flows need to implemented as workflows that span multiple microservices.

Problem​

  • There is added complexity since the synchronosity of the implemented workflows between microservices does not match the async/sync nature of the business flows.
    • Example: microservice communicate using asynchronous events to emulate a synchronous request-response interaction model.
    • Examplle: microservices communicate using synchronous request-response but the client of the request is not interested in the response.

Solution​

Align the synchronisity of the workflow between microservices to the nature of the underlying business flow.

A business flow represents the flow of a process in the target domain of the application. A business flow can be synchronous or asynchronous depending if you wait for a result of a process step or not.

By aligning the synchronisity workflow to the nature actual business flow allows to avoid the complexity of emulating sync/async business flows with async/sync workflows. This simplifies reasoning about the system and its underlying domain since no translation into the other paradigm has to be factored in. The decision on how to implement workflows will affect the technical implementation down the line.

However, this might mean having synchronous and asynchronous workflows in the system. This is a trade-off since supporting multiple workflow mechanisms might mean added complexity.

If you decide for asynchronous workflows, you need to consider its drawbacks. The asynchronous way of thinking often needs to be learned, e.g., by using education programs first. Alternative paths in use-cases need to become first-class citizens in order to cope with error handling.

Please note that the workflow type (sync. vs. async.) is generally independent from

However, choreography naturally aligns well with asynchronous workflows, and orchestration aligns well with synchronous workflows but can also be implemented as asynchronous workflow.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L42:

  • cite of a participants:
    • "Thinking in terms of workflows helped us comprehend better the business of our customers and so we ended up with an architecture that had better similarities to the actual business"
  • less common activity: carefully design business workflow processes

Interview B:

  • Challenge for developers from enterprise: think on domain level instead on technical level
  • Example: automotive
    • important to order messages in order (for client sessions)
    • but only important for one single use-case (using a client session), not important for all other use cases
    • Decision: sequential queue to support the ordering
      • but for all use cases "to be on the save side" => from domain perspective unnecessary
      • blocking queue => slow, error prone
  • Prefer to use events (async)
    • more complex in terms of thinking patterns
    • more complex monitoring (progress of workflow)
    • you can emulate req/resp with events => + timeouts
  • Sync vs. async
    • need to grow into way of thinking for async workflows
    • need to make negative/alternative paths first-class citizens for async
      • sync: easy, catch exception

Interview C:

  • Comm. structure orients on business processes
    • not sure if it fits to 100%
  • BPNM and EPK
    • EPK => events
    • BPNM => process tokens (states)
  • Streams as 3rd paradigm
  • Some applications have all 3 paradigms as independent levels
    • connecting a partial graph of overall application

Interview D:

  • domain comm. style vs. technical comm. style
    • often neglected: Microservices => REST! No?! How about events?
    • both exist: req-resp vs. async.
  • Example for async. business flow: insurance application workflow
    • Example steps
      • application arrives
      • solvency check
      • fraud check
      • review
      • issuing (dt. Policierung)
      • ...
      • => insurance policy issued or rejected
    • Independent steps => more a flow
  • Example for async business flow: e-commerce order fulfillment
    • Steps
      • Customer clicks "buy now"
      • multiple things happen now
  • Choose technical comm pattern dependent on business flow
    • you can emulate,
      • e.g. asnyc flow via REST
      • e.g. sync req-resp via events
    • but is not really natural
    • people from SOA claiming SOAP doesn't fit on HTTP (tunneling) should cry out loud now, but don't
  • Recommendation: adapt technical comm. style to business flows
    • emulate with technical means a domain communication
    • prevents adding unwanted complexity
    • stay in the correct way of thinking (no gap)
    • TRADE-OFF: more complex than just take one universal comm. style if you end up with multiples

Interview F:

  • Context: department boundaries as good guideline for service decomposition
  • Interaction should be attributable to a microservice - you also don't want to be forwarded from department to department
  • But there might be dependent services/departments doing stuff in the aftermath
    • condidate to decide whether async or sync
    • if in aftermath => async
    • architecture pholosophy topic
    • requires much work to get there
  • Context: strong consistency
    • only within microservice instalces
    • cannot just write down sequence => much can happen in between
    • need for a strategy to cope with all these cases
      • is it okay that user doesn't get answer interactively but over an async service
      • how do I order requests of the same type
    • avoid distributing strongly consistent things
      • if exaggerated, end up wiith monolith
      • possibiliy: forward asynchronously
        • if need to go to other service => already processed data and make sure the state on the original service doesn't have to change