Watch note for The hardest part of microservices is your data
slides:
https://www.slideshare.net/ceposta/the-hardest-part-of-microservices-your-data
slides:
https://www.slideshare.net/ceposta/the-hardest-part-of-microservices-your-data
- Microservices is about optimizing for SPEED.
- Manage (aka. reduce) dependencies.
- Data is a major dependency.
- Focus on domain models, not data models
- Stick with these conveniences as long as you can.
- A microservice has its own database
- We need to understand something about the data inside our services and the data outside our services
- Thus, we are building a distributed system, thus, beware of
- network latency,
- network partition
- Plan for failures.
- Build concepts of time, delay, network, and failures into the design as a first-class citizen
- How do you “read” data and how do you “update” data.
- Separate reads and writes
(CQRS, Command Query Responsibility Segregation
refer to: http://vsdmars.blogspot.com/2018/05/design-even-driven-system-pattern.html - Performance: N+1 Query Problem
- https://secure.phabricator.com/book/phabcontrib/article/n_plus_one/
- Use Batching Queries to fix it!
- Load all your data before iterating through it.
- Detecting the Problem
- If seeing a bunch of similar queries, this often indicates an N+1 query issue(or a similar kind of query batching problem)
- For our reads and writes, we need some "consistency"
- We need reads and writes. But we expect failures.
- CAP tells us to pick 2: Consistency, Availability, Partition Tolerance
- CAP is a bad way to think about this.
- Consistency model
https://en.wikipedia.org/wiki/Consistency_model - What consistency model do you need, depending on what role you’re playing?
