Serverless Highly Coupled Components
Serverless is one of the most interesting designs in the last years and this community is growing well, but it keeps the distributed challenges and tries to resolve them.
Before presenting the solution lets have a look at distributed coupling.
When discussing about Software dependencies there are the Static and Dynamic Dependencies, where the static ones are highly related to your software coding and the dynamic ones are related to your external dependencies. In this article we focus on dynamic ones.
Again when categorizing the dynamic dependencies we have the Highly Coupled ones and loosely coupled ones.
In This Article we will talk about highly coupled one and presenting the callback design patterns in Serverless design.
Highly Coupled Dependency:
These are the dependencies in which our business flaw can not be realized without a response, in other words, these are the dependencies which could be part of your system but are decoupled as a distributed component to take advantage of agility and microservice architecture.
This decoupling helps to let the account and payment systems be delivered independently without any impact on the other service.
But how we can process our design where the account service has so many failures, the payment service will do kind of circuit breaking , retry or fallback to handle the situation but when we talk about resiliency we say any service needs to manage well its failures. Yeah? and what ever is the reason, that will be its concern of resiliency.
A reliable service knows its exigences and priorities better that other parts
We now need to let the Account system manage that failure well without impacting the rest of process.
Lets have a look at Account design first, and we will follow the payment next.
To Obtain Performance, Resiliency and Operation in a agile manner this is preferable for a gain in term of business.
In this design we decoupled any process by its proper Dead Letter Queue and its retry system and we could decouple the responsibility of account operations into account service. now how payment system will interact with this system.
This is simple: The payment request is in running state , it calls the Account system saying that i need this data to process this payment, next it will wait for the response and let the account service do its best.
Lets design the Payment system:
The Payment service receives the payment request , this is followed by a simple model validation and verifying if required information are presented, the payment execution will be started and a tokenized request with callback will be sent to account system.
1- It generates a token for payment
2- It has a time out for payment execution
2- The Payment id is registered to a database alongside with generated token
3- The execution state becomes Paused from Running
3- The request is initiated to the Account service
5- Account service will push the result to its Pub/Sub broker
6- Payment service is subscribed to the broker to be notified of any result
7- The Payment service with re-run the payment execution
8- The State of execution is changed to Running or resumed.
9- The Payment is treated and the result will be notified to Email service, Delivery service and etc..
This design adds some components but keeps your system decoupled , resilient and real.
