Book Image

Microservice Patterns and Best Practices

By : Vinicius Feitosa Pacheco
Book Image

Microservice Patterns and Best Practices

By: Vinicius Feitosa Pacheco

Overview of this book

Microservices are a hot trend in the development world right now. Many enterprises have adopted this approach to achieve agility and the continuous delivery of applications to gain a competitive advantage. This book will take you through different design patterns at different stages of the microservice application development along with their best practices. Microservice Patterns and Best Practices starts with the learning of microservices key concepts and showing how to make the right choices while designing microservices. You will then move onto internal microservices application patterns, such as caching strategy, asynchronism, CQRS and event sourcing, circuit breaker, and bulkheads. As you progress, you'll learn the design patterns of microservices. The book will guide you on where to use the perfect design pattern at the application development stage and how to break monolithic application into microservices. You will also be taken through the best practices and patterns involved while testing, securing, and deploying your microservice application. At the end of the book, you will easily be able to create interoperable microservices, which are testable and prepared for optimum performance.
Table of Contents (20 chapters)
Title Page
Dedication
Packt Upsell
Contributors
Preface
Index

Event sourcing – data integrity


Before going directly onto the theme of event sourcing, it is necessary to understand the functioning of most standard applications.

Whenever we run the command UPDATE in the database, we perform a modification to our current representation in the database. With that, whenever we do a query on the database, we seek the current state of a record. This behavior is called state mutation. Let's use an example to make it clearer.

State mutation

Suppose we have a table responsible for administering the access level of a user. The table is composed as follows:

ID

user_name

status

user_manager

1

John Doe

admin

Manager1

 

As we look at the preceding table, we see that the user John Doe is an administrator and this status was applied by Manager1. After a period of time, it was found that John Doe could never have been the admin of the application and an UPDATE is performed on this row in the table:

UPDATE status_user set status='normal_user', user_manager='Manage2' WHERE ID=1; 

This...