Microservice design patterns

There are many design patterns for building microservices, and most of them are wrong. Actually, that is not true. The fundamental objectives for implementing microservice systems are speed and agility. Speed, of course, is how quickly you can get things done. Regardless of what design patterns you use, if you can quickly build, fix, enhance, and rapidly evolve your microservices, you are heading in the right direction. Agility is the flexibility to move rapidly across the entire development lifecycle while living happily in production.

But we can always do better. Right?

That is what this talk is about. We will take a look at some of the more common microservice design patterns. And we will compare them to some of the alternatives. For example, what is the more common microlith design pattern, and how getting serious about loose coupling guides the evolution to ways that increase your speed and agility? We will also look at why it is micro at the code level and the data level. Finally, we will cover some practical guidelines, such as why your microservices should do the least amount of work while your users are waiting and techniques for doing that.

1. Microservice
Design Patterns
Hugh McKee
Developer Advocate
@mckeeh3

2. Take a moment to flex your mind







This won’t hurt - much

3. There is a boat full of people

The boat capsizes

Not a single person gets wet

How can this happen?


Pattern Flexibility

4. There is a boat full of people

The boat capsizes

Not a single person gets wet

How can this happen?

They are all married!
Pattern Flexibility

5. Pattern Flexibility
5 + 5 + 5 = 550

Add one line to correct this expression

6. Pattern Flexibility
5 + 5 + 5 = 550

Add one line to correct this expression

7. My
Ask

8. Progression of design patterns

14. What is a Microlith?
A microlith is a distributed monolith.

●Microservices are tightly coupled
●Monolithic database
What are tightly coupled
microservices?
Have RPC dependencies with other
microservices.

Communicate synchronously via RESTful
RPC calls with other microservices.

24. What happens
when, not if, WHEN
something fails?

29. Something
went wrong.
Please try
again later.

30. Tightly coupled synchronous RESTful RPC

31. Tightly coupled synchronous RESTful RPC

32. Tightly coupled synchronous RESTful RPC

33. Tightly coupled synchronous RESTful RPC

34. Loose Coupling
Event driven asynchronous communication

35. Loosely coupled asynchronous messaging

36. Loosely coupled asynchronous messaging

37. Loosely coupled asynchronous messaging

38. Loosely coupled asynchronous messaging

39. Still a Microlith?
Best effort to decouple all or most
microservices.

Database is still monolithic.

40. Loosely coupled microservices
Asynchronous intra service
messaging

Each service owns its own
schema/data


Shared outside perspective

Hidden private inside perspective

41. Each microservice owns its own schema/data

42. Outside perspective

43. Inside perspective

44. Outside perspective

45. Event Oriented Microservices
Do the least amount of work while
someone or something is waiting

Push work out-of-band done
asynchronously in the background

49. Goals - not rules - to guide how you build your microservices
Implement loosely coupled microservices - asynchronous messaging

Make asynchronous messaging the norm, synchronous messaging the exception

Each microservice owns its own schema

Turn data reference sources (e.g. customer data) into data change publishers

Make event-oriented the norm, traditional CRUD the exception

Always do the - when this thing breaks - analysis to uncover weak, brittle patterns

50. Goals - not rules - to guide how you build your microservices
Implement loosely coupled microservices - asynchronous messaging

Make asynchronous messaging the norm, synchronous messaging the exception

Each microservice owns its own schema

Turn data reference sources (e.g. customer data) into data change publishers

Make event-oriented the norm, traditional CRUD the exception

Always do the - when this thing breaks - analysis to uncover weak, brittle patterns

51. Goals - not rules - to guide how you build your microservices
Implement loosely coupled microservices - asynchronous messaging

Make asynchronous messaging the norm, synchronous messaging the exception

Each microservice owns its own schema

Turn data reference sources (e.g. customer data) into data change publishers

Make event-oriented the norm, traditional CRUD the exception

Always do the - when this thing breaks - analysis to uncover weak, brittle patterns

52. Goals - not rules - to guide how you build your microservices
Implement loosely coupled microservices - asynchronous messaging

Make asynchronous messaging the norm, synchronous messaging the exception

Each microservice owns its own schema

Turn data reference sources (e.g. customer data) into data change publishers

Make event-oriented the norm, traditional CRUD the exception

Always do the - when this thing breaks - analysis to uncover weak, brittle patterns

53. Goals - not rules - to guide how you build your microservices
Implement loosely coupled microservices - asynchronous messaging

Make asynchronous messaging the norm, synchronous messaging the exception

Each microservice owns its own schema

Turn data reference sources (e.g. customer data) into data change publishers

Make event-oriented the norm, traditional CRUD the exception

Always do the - when this thing breaks - analysis to uncover weak, brittle patterns

54. Goals - not rules - to guide how you build your microservices
Implement loosely coupled microservices - asynchronous messaging

Make asynchronous messaging the norm, synchronous messaging the exception

Each microservice owns its own schema

Turn data reference sources (e.g. customer data) into data change publishers

Make event-oriented the norm, traditional CRUD the exception

Always do the - when this thing breaks - analysis to uncover weak, brittle patterns

55. Goals - not rules - to guide how you build your microservices
Implement loosely coupled microservices - asynchronous messaging

Make asynchronous messaging the norm, synchronous messaging the exception

Each microservice owns its own schema

Turn data reference sources (e.g. customer data) into data change publishers

Make event-oriented the norm, traditional CRUD the exception

Always do the - when this thing breaks - analysis to uncover weak, brittle patterns

56. Goals - not rules - to guide how you build your microservices
Implement loosely coupled microservices - asynchronous messaging

Make asynchronous messaging the norm, synchronous messaging the exception

Each microservice owns its own schema

Turn data reference sources (e.g. customer data) into data change publishers

Make event-oriented the norm, traditional CRUD the exception

Always do the - when this thing breaks - analysis to uncover weak, brittle patterns

57. “At the heart of science is an essential
balance between two seemingly
contradictory attitudes--an openness to
new ideas, no matter how bizarre or
counterintuitive they may be, and the
most ruthless skeptical scrutiny of all
ideas, old and new. This is how deep
truths are winnowed from deep
nonsense.”

Carl Sagan
computer
^

58. Microservice Design
Patterns



See these patterns in action
with Akka Serverless open beta



Thank you!

Hugh McKee
Developer Advocate
@mckeeh3