This document discusses microservices, distributed computing, and the CAP theorem. It provides motivation for scaling applications using microservices and distributed systems by discussing increasing internet traffic over time. It introduces concepts of vertical and horizontal scaling. It discusses distributed system fundamentals of consistency, availability, and partition tolerance. It explains the CAP theorem and tradeoffs between consistency, availability and partition tolerance. It discusses data management approaches of ACID and BASE and types of consistency like strong, weak and eventual consistency.

1. MICROSERVICES,
DISTRIBUTED COMPUTING
& CAP THEOREM
28/10/2018

2. Orhan Burak Bozan
Software Architecture
& Automation Consultant

3. OUTLINE
● MOTIVATION
● SCALING
● DISTRIBUTED SYSTEMS FUNDAMENTALS
● CAP THEOREM
● DATA MANAGEMENT – ACRONYMS
● CONSISTENCY TYPES
● EVENTUAL CONSISTENCY

4. MOTIVATION
● CONCEPTUAL OVERVIEW
● THINKING DISTRIBUTED
● SCALING

5. INTERNET TRAFFIC OVER TIME

6. MICROSERVICES TREND

7. TRAFFIC

8. HOW TO HANDLE MORE TRAFFIC?

9. TRADITIONAL APPLICATIONS
ACID RDBMS
MONOLITH
APP

10. TRADITIONAL APPLICATIONS

11. HOW TO HANDLE MORE TRAFFIC?
● SCALING
○ SCALE UP - VERTICAL SCALING
○ SCALE OUT - HORIZONTAL SCALING

12. VERTICAL SCALING
● Adding more resources to the server
● Advantages
○ No extra development
○ Less Networking
○ Better for process intensive apps
● Disadvantages
○ Extra Cost
○ Risky

13. HORIZONTAL SCALING
● Adding more servers w/ less capacity.
● Advantages
○ $ $ $ CHEAPER $ $ $
○ More fault tolerant
○ Better for enterprise apps
● Disadvantages
○ Complex design
○ More Networking

14. HORIZONTAL OR VERTICAL SCALING?
● Cost effectiveness
● Single Source of Failure

15. HORIZONTAL SCALING, BUT HOW?

16. HORIZONTAL SCALING, BUT HOW?
● SCALE CUBE
○ by Michael Fisher

17. X AXIS SCALING
● Horizontal Duplication
● Scale by Cloning Services

18. Y AXIS SCALING
● Functional Decomposition
● Scale by Using Microservices
● Polyglot Persistence

19. Y AXIS SCALING

20. Y AXIS SCALING

21. Z AXIS SCALING
● Data Partitioning
● Scale by Sharding Databases

22. MULTI DIMENSIONAL SCALING

23. SCALABLE DISTRIBUTED APPLICATIONS

24. SCALABLE DISTRIBUTED APPLICATIONS
● Networked Shared Multi Resource Systems

25. FUNDAMENTALS
● COMMON PITFALLS IN DISTRIBUTED COMPUTING
○ Consistency
○ Availability
○ Partition Tolerance

26. FUNDAMENTALS - CONSISTENCY
● Every read receives the most recent write or an
error.
● ex. If I get my cart on my shopping site, it must
contain all the previously added items.

27. FUNDAMENTALS - AVAILABILITY
● Every request receives a (non-error) response –
without guarantee that it contains the most recent
write
● ex. I will eventually Access my shopping cart.

28. FUNDAMENTALS - PARTITION TOLERANCE
● The system continues to operate even if there is a
partition / communication break
● ex. I should go shopping on my shopping site in a
partition.

29. CAP THEOREM
● “Of three properties of shared-data
systems (Consistency, Availability and
tolerance to network Partitions) only two
can be achieved at any given moment in
time.”
● 2000: Eric Brewer, PODC conference
keynote

30. CAP THEOREM

31. CA - FORFEIT PARTITIONS
● High-Availability Consistency
● 2-Phase Commit
● Single-site databases, Oracle,
Postgres, MySQL

32. CP - BEST EFFORT AVAILABILITY
● Strong Consistency w/ Partition
Tolerance
● Pessimistic Locking
● DNS, MongoDB, Redis

33. AP - BEST EFFORT CONSISTENCY
● Relax consistency in order to achieve
full availability.
● Optimistic locking
● Hazelcast, CouchBase, Cassandra

35. DATA MANAGEMENT - ACRONYMS
● ACID
○ Traditional monolith systems
○ RDBMS
● BASE
○ Distributed Systems

36. ACID
● ATOMIC
○ each transaction be "all or nothing"
● CONSISTENT
○ any transaction will bring the database from one valid state to another
● ISOLATED
○ transactions doesn’t interfere / concurrency
● DURABLE
○ once a transaction has been committed, it will remain so

37. BASE
● BASICALLY AVAILABLE
○ System mostly available and there might be subsystems temporarily
unavailable
● SOFT STATE
○ The state of system could change over time, even without any input.
● EVENTUAL CONSISTENT
○ Eventually all accesses will return the last updated value

38. CONSISTENCY TYPES
● STRONG CONSISTENCY
○ All subsequent accesses return the updated value after the update.
● WEAK CONSISTENCY
○ Subsequent accesses might not always be returning the updated value.
● EVENTUAL CONSISTENCY
○ Given, if no new updates to a data item, eventually all accesses to that
item will return the last updated value

39. EVENTUAL CONSISTENCY - EXAMPLES
● ALIEXPRESS
○ Payment
● INSTAGRAM
○ New follower
● SHAKE SHACK
○ Shaking Control

40. NEXT ...
● Restful Services
● Containerization
● Orchestration & Choreography
● Service/Resource Discovery
● API Gateway
● Event Sourcing & CQRS
● Eventapis

42. REFERENCES
● https://www.nginx.com/blog/introduction-to-microservices/
● http://microservices.io/
● https://en.wikipedia.org/wiki/Two-phase_commit_protocol
● https://en.wikipedia.org/wiki/CAP_theorem
● http://www.vtagion.com/scalability-scale-up-scale-out-care/
● https://en.wikipedia.org/wiki/Eventual_consistency
● http://www.fredberinger.com/2009/12/musings-on-nosql/
● http://blog.nahurst.com/visual-guide-to-nosql-systems
● http://broabandtrafficmanagement.blogspot.com.tr/2012/01/itu-internet-bandwidth-has-grown.html

43. Questions?
Orhan Burak Bozan
Senior Software Engineer
https://www.linkedin.com/in/bozan
http://microservices.kloia.com
https://github.com/kloiasoft/eventapis