This document discusses microservices architecture and monolithic architecture. It notes that eventual consistency with microservices means that during a partition, different processes may see different data states. Intermittent failures can also cause issues as any call in a microservices process can fail at any time. While microservices are good for very large complex systems, monolithic design should not be dismissed and may still be preferable for smaller teams or early products where independence of delivery is not as important. The best architecture depends on factors like team size, product stage, domain knowledge, and independence requirements.

1. You’re not Netflix
UXDX Amsterdam

2. Ronald van Rijn

3. About the title

4. Once upon a time…

5. Microservices Premium

6. Eventual consistency
Service A Service B
Process 1 Process 2
Write 2
Write 1 Read 1
Read 2
Due to partitioning process 2 might read any of the following:
only write 1, only write 2, both or neither

7. Intermittent failures
Service A Service B
Process 1 Process 2
Failed write
Write Read
Read
Due to the nature of network traffic any call can fail,
at any time and anywhere in the process

9. “Don’t even consider microservices unless you
have a system that is too complex to manage
as a monolith.”
— Martin Fowler, Thoughtworks

10. In defence of Monoliths

11. “Don’t start a monolith when your
goal is a microservices architecture.”
— Stefan Tilkov, innoQ

12. Architectures lie on a spectrum

13. Size of your engineering team

14. Stage of the product or concept

15. Domain knowledge of the team

16. Requirement to deliver part of
the system independently

17. In conclusion

18. Thank you!