Microservices - Design Patterns

Topic: Software Design                                                                                  Level: Intermediate

Microservices - What?

Microservice is a software design methodology, delegated to perform an isolated decoupled single functionality (following the Single-Responsibility Principle from object-oriented SOLID design principles). 

Moreover, microservices by design, are decoupled making it easy to develop, test, maintain, deploy, configure, monitor and scale modules independently.

Microservices - Why?

Having one microservice would not be helpful without it being able to interact with other microservices, to aid in bringing an end-to-end business solution. So arises a question, how can I design a software system that is resilient, decentralized, fault-tolerant, scalable, maintainable, and extensible that complies with the microservice architecture?

Design Patterns - What?

Design patterns are solutions for commonly occurring problems within a given context.

As the businesses and systems evolve on the use-cases, we tend to build on the software by introducing new features and creating more code thereby slowly shifting into the realm of complexity in extensibility and maintainability (how fast the feature can make it to the market?).

How can we arrive at a medial balance point that doesn't tip on either side of code complexity nor flexibility in feature addition?

An image from Twitter (not sure of the source though) categorizing the design patterns that could be employed on Microservice architectures.

The standard object-oriented software GoF (Gang of Four) design patterns are broadly classified into,

• Creational
• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton
• Structural
• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy
• Behavioural
• Chain of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor

For more details on the design implementation and references, please check out my GitHub page, here

Microservice Design Patterns - Architectural system-oriented design patterns are broadly classified into,

• Decomposition Patterns
• Business Capability
• Subdomain
• Transactions
• Strangler
• Bulkhead
• Sidecar
• Integration Patterns
• API Gateway
• Aggregator
• Proxy
• Gateway Routing
• Chained Services
• Branch
• Client-Side UI Composition
• Database Patterns
• Database per Service
• Shared Database per Service
• Command Query Responsibility Segregation (CQRS)
• Event Sourcing
• Saga 
• Observability Patterns
• Log Aggregation
• Performance Metrics
• Distributed Tracing
• Health Check
• Cross-Cutting Concern Patterns
• External Configuration
• Service Discovery
• Circuit Breaker
• Blue-Green Deployment

And in the upcoming series of posts, we will get into detail on each of the microservices design patterns and their intricacies.

Let's lance them!

---

Disclaimer: 
This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual. All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Downloadable Files and Images
Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.

• Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to :
• Comments deemed to be spam or questionable spam.
• Comments including profanity.
• Comments containing language or concepts that could be deemed offensive.
• Comments containing hate speech, credible threats, or direct attacks on an individual or group.

The blog owner is not responsible for the content in the comments.
This blog disclaimer is subject to change at any time.