Book Image

Scala Microservices

By : Selvam Palanimalai, Jatin Puri
Book Image

Scala Microservices

By: Selvam Palanimalai, Jatin Puri

Overview of this book

<p>In this book we will learn what it takes to build great applications using Microservices, the pitfalls associated with such a design and the techniques to avoid them. </p><p>We learn to build highly performant applications using Play Framework. You will understand the importance of writing code that is asynchronous and nonblocking and how Play leverages this paradigm for higher throughput. The book introduces Reactive Manifesto and uses Lagom Framework to implement the suggested paradigms. Lagom teaches us to: build applications that are scalable and resilient to failures, and solves problems faced with microservices like service gateway, service discovery, communication and so on. Message Passing is used as a means to achieve resilience and CQRS with Event Sourcing helps us in modelling data for highly interactive applications. </p><p>The book also shares effective development processes for large teams by using good version control workflow, continuous integration and deployment strategies. We introduce Docker containers and Kubernetes orchestrator. Finally, we look at end to end deployment of a set of scala microservices in kubernetes with load balancing, service discovery and rolling deployments. </p><p></p>
Table of Contents (12 chapters)

Event Sourcing and CQRS

Event sourcing and Command Query Responsibility Segregation are frequently mentioned together. Although neither one necessarily implies the other, but they do complement each other.

In our CQRS explanation, we had observed the following diagram:

Events in a way act as synchronization of data on the write-side with the read-side. Once the data is synced with the read side, the read side stores the data in a fashion that makes it very fast to read (denomalized data?).

We could improvise our model by including Event Sourcing in the picture. On the write side, when a command is received, instead of persisting data in its own data model. The write side would generate events, append it to its event store and finally push it towards the read side.

The write side manages the event side, and pushes all the updates made on the write-side as events towards the read...