3. Connected Patterns

What you’ll learn

In this section of the Connected Integration Blueprint (CIB) you’ll learn about:

• Core interaction scenarios
• Common architectural / integration patterns that can be adopted

Interaction Scenarios

As discussed in the previous 2 sections, when building a connected integration into Marketplacer, you’ll need to consider the data that you want to move between parties. So far we’ve only really looked at individual data flows, but not the “bigger picture” from an end to end perspective. In this section we’ll look at the end to end interaction scenarios that will assist in understanding that bigger picture.

We will look at each of the following interaction scenarios:

• Product Sync (including inventory)
• Orders Placement (Including shipment notifications)
• Refunding
• Seller Creation & Remittance Notification

Fast Vs. Slow Moving Data

Before looking at the interaction diagrams for each context, it’s worth discussing Fast Vs Slow moving data. For the purposes of this discussion we we’ll use the following definitions.

Fast Moving

Fast moving data is when a particular class of data needs to traverse between solution components in as short a time-frame as possible. I.e. there would typically be pressing commercial or operational reasons why this data would have to move faster than others.

Examples of this type of data are:

• Order data. You would expect the placement of an order on the front end eCommerce platform to traverse successfully through to Marketplacer without significant delay. You would not typically want to “batch” this type of data.
• Inventory Data. Depending on how you have Marketplacer set up, the inventory position of a given product can change via a number of channels. Therefore, you would typically always want those changes to be reflected across solution components quickly.

Slow Moving Data

Slow moving data is basically anything that does not need to move “fast”. While you will of course always attempt to move data as quickly and correctly as possible, when compared with fast data classifications, slow moving data just does not need to move as quickly.

Product Interaction

Order Creation

Refunds Interaction

Note: This is one of many possible interaction examples for refunding.

Seller Interaction

Connected Patterns

So far we’ve represented out architecture as follows:

While this was sufficient for our prior discussions, your solution landscape may not be as straightforward, with multiple points of integration, for example:

This of course is one of many different possible permutations.

While we cannot cover every possible configuration that may exist, what this section provides as a number of common patterns that you could follow when building an integration.

For each pattern we have outlined the suggested interaction point that could be used:

• (Q) GraphQL Query
• (M) GraphQL Mutation
• (W) Webhook

1: API Only

• Monolithic integration layer
• Uses API calls only
• API Polling would be used for updates
  • Suggest using a single Variant node query for individual inventory position updates
  • For “batch” updates the advertsWhere query would be better employed
• Pattern suitable for smaller / simpler domains

2: API & Webhook

• 2 “large” services
  • Write Service: uses API Mutations
  • Read Service: uses Webhooks
    • Allows for event-based updates
• Still only a single downstream system
  • Pattern suitable for smaller / simpler domains

3: API Services with 1 Webhook Endpoint

• Multiple “Write” services
• Single “Read” Service (Webhooks)
  • Acts as a webhook “router” / “de-duplicator”
  • Can determine webhook payload deltas
  • Routes to message bus topic
  • Protects downstream systems from redundant messages
  • Single point of failure
  • You can leverage the benefits of the Message Bus
• Suited to larger more complex domains

4: API Services with multiple Webhook Endpoints

• Multiple “Write” services
• Multiple “Read” services
  • Feed direct to upstream systems
  • No single point of failure
  • Payload deltas could be performed at each endpoint
  • Increased distributed systems complexity
• Suited to larger more complex domains

5: Webhook Primary / API Secondary

• Primarily use Webhooks for Product updates
• Use batch querying to perform back-up reconciliation of product updates
• More of a “sub-pattern”, it could be employed:
  • In other pattern examples
  • Using a different data type (not just products)

6: Webhook with API Callback

• 1. Use webhooks to pass only single object IDs (no detailed product payload)
• 2. Use a node query to retrieve desired detailed product data
• Removes the need to edit / alter webhook query config in Marketplacer and retain that in the integration service
• More “chatty” pattern
• More of a “sub-pattern”, it could be employed:
  • In other pattern examples
  • Using a different data type (not just products)