Couple of Minutes: Serverless Microservices Patterns
We introduced our serverless microservices architecture in the previous post. Let’s look at different patterns visible in this architecture.
Below is the 2D version of the same architecture for reference.
Below are some patterns that are visible in the architecture.
Application Architecture Pattern: We have chosen to explore Microservices architectural pattern here. So we are not left with choices.
Decomposition: We have decomposed services by business capability (used verbs here). We will pick up this pattern for a review in our next post.
Communication Style: We have used 3 patterns here. API Gateway Pattern is used for communication between UI client and our services. API Gateway is also used for synchronous request-response communication between our lambda functions (getDigiAds invoking getMetadata). Messaging is used for asynchronous pub/sub communication (communication between extractMetadata and addMetadata. Amazon S3 always invokes a Lambda function asynchronously). Remote Procedure Invocation is used for communication between our services and 3rd party APIs (Deals, Rekognition).
Deployment: we have chosen to explore serverless. So this is an obvious pattern to use here. But we will have to look at how we can enable continuous integration and continuous delivery.
Below are few must-have patterns that are not visible in the architecture, but we would explore during design and implementation
Reliability: We will explore Circuit Breaker pattern to see how we can make it fail-safe. Even if there are failures, they have to be graceful. Circuit breaker will be cost effective wherever we have synchronous request-reply service requests (to other lambda functions or 3rd party APIs) from our lambda functions. Remember, Lambda functions are billed for their execution time. The longer they wait on a call that’s gonna fail, the more we spend for waste.
Observability: We will explore Log Aggregation with CloudWatch logs and Distributed Tracing using X-ray.
