Design patterns
We all probably know the story of Sisyphus. The king who was punished for cheating death twice, by being forced to roll an immense boulder up a hill only for it to roll down every time it neared the top, repeating this action for eternity.
It’s probably the worst feeling, when one has to repeat a mundane task over and over for eternity.
The fun part of being a Software Engineer is being able to solve new problems. It’s incredibly painful if one has to repeat the solution over and over again. That is why identifying patterns becomes so important.
As engineers we always look for reusable solutions to a commonly occurring problem within a given context in software design. These templates(or solutions) later on are often formalized as best practices or standards.
Few extensively used microservices design patterns in the industry today :
Sidecar Pattern
The term sidecar is a one-wheeled device attached to the side of a motorcycle. Sidecar cannot run independently without being attached to a motorcycle.
This is also referred to as the sidekick pattern. Just like in movies, we have a main character that fights the villain and saves the day. We also have associates that add power to our main character in different ways.
There are applications that does the core business functionality and other components that add more value to the overall flow.
Sidecar patterns can actually do some powerful functionalities too, and not necessarily peripheral tasks like logging.
In an event driven architecture, these could be used as a trigger for other business functionalities or could be a significant contributor in building a resilient application.
Suppose we have a User Login application which after successful authentication, loads certain data (Grocery list, Apparel etc..) based on consumer request. Instead of waiting for the actual call to happen, we could pre-warm the cache as soon as the User Login receives the request.
When the actual request is received, the response would be faster, as it is served from the cache.
In the above diagram, a sidecar within the User Login application acts as a trigger to pre-warm the cache before the actual call.
If you are using a Spring boot framework, you could easily implement this by using filter based pattern.
Above picture depicts an asynchronous filter based call that acts as a sidecar without interfering with the main application flow.
For more info: Spring-Routing & filtering
This could also be used in building resilient applications that use other patterns like audit logging.
Audit logging pattern
Another challenge to address in microservices architecture, which can potentially have hundreds of distributed services, is ensuring visibility of user actions on each service and being able to get a good overall view across all services at an organizational level.
Changes should ideally be tracked at the individual service level as well as, across services running on the wider system.
Typically, these changes occur frequently in microservices architecture, which makes auditing changes even more important.
Audit logging is a pattern that helps keep track of all transactions in a persistent store.
It is helpful to know what actions a user has recently performed: customer support, add to a cart, transaction, security, etc.
This could be implemented using the sidecar pattern explained above.
In the above picture, all the microservices have implemented an audit logging feature as a sidecar. This could be a common library and could be invoked at a filter level (if you are using java and as explained in the sidecar pattern section)
External Configuration Store pattern
Every application needs configuration.
This could be to either store sensitive information like database username/password it’s connecting to, or other details like number of retries when a connection failure happens.
Some applications’ runtime environments include configuration information that’s held in files deployed with the application. It’s possible to edit these files to change the application behavior after it’s been deployed.
However, changes to the configuration require the applications to be redeployed, often resulting in unacceptable downtime and other administrative overhead.
Local configuration files also limit the configuration to a single application, but sometimes it would be useful to share configuration settings across multiple applications. eg: database connection strings, URLs of queues and storage used by a related set of applications.
Many configuration systems don’t support different versions of configuration information and not to forget about implementing encryption logic for sensitive data every single time.
Store the configuration information in external storage, and provide an interface that could be used to quickly and efficiently read and update configuration settings.
Spring provides in built support to access external config making development effort a lot easier.
For more info : Spring- Externalizing config
Other Patterns
There are hundreds of other patterns which have been identified and it evolves as technology progresses.
Here are few interesting reads
Conclusion
Pattern recognition is inherent to human beings.
It is something we have been doing since our early evolution days. Few of my favorite quotes by Neil deGrasse Tyson
The best thing we have going for us is our intelligence, especially pattern recognition, sharpened over eons of evolution.
Interestingly, we are sometimes too desperate to find a pattern (which probably does not exist!) as beautifully put by Neil deGrasse Tyson in his series Cosmos :
The human talent for pattern-recognition is a two-edged sword: We’re especially good at finding patterns, even when they aren’t really there — something known as false pattern-recognition.
We hunger for significance — for signs that our personal existence is of special meaning to the universe. To that end, we’re all too eager to deceive ourselves and others.
