Professional Documents
Culture Documents
h"p://bit.ly/ceposta-hardest-part
Christian Posta
Principal Architect Red Hat
Twitter: @christianposta
Blog: http://blog.christianposta.com
Email: christian@redhat.com
Weekly reporBng
RecommendaBons
Focus on domain models, not data models
Break things into smaller,
understandable models
Surround a model and its
context with an explicit
boundary
Implement the model in code
or get a new model
Explicitly map between
different contexts
Model transactional
boundaries as aggregates
SBck with these conveniences as long as you can.
Seriously.
But ...
Load/size is too great to t on one box
Modules/use cases have dierent read/write characterisBcs
Queries/joins are geOng too complex
Security issues
Lots of conicBng changes to the model/schema
Need denormalized, opBmized indexing engines
We want to explicitly reduce dependencies on data between
our services
From here on out, what were saying is thank you old
work-horse database, weve got it from here
A microservice has its own database
Were now building a full-edged
data-centric distributed system.
Some things to remember
Plan for failures.
Build concepts of Bme, delay,
network, and failures into the
design as a rst-class ciBzen.
h"ps://secure.phabricator.com/book/phabcontrib/arBcle/n_plus_one/
getBulkHats()
getBulkHatsForCatsExcept()
wellReallyIJustWantCertainHats()
justExecuteThisSqlForMe()
h"ps://secure.phabricator.com/book/phabcontrib/arBcle/n_plus_one/
We need consistency. But we expect failures. This is
starBng to sound like CAP
Consistency models
h"ps://en.wikipedia.org/wiki/Consistency_model
Replicated Data Consistency Explained through Baseball
(Doug Terry)
Twitter: @christianposta
Blog: http://blog.christianposta.com
Email: christian@redhat.com