83 lines
3.1 KiB
Org Mode
83 lines
3.1 KiB
Org Mode
:PROPERTIES:
|
|
:ID: 9de8fa16-17f9-4877-a24f-a0df7a88c53e
|
|
:END:
|
|
#+title: Distributed Systems
|
|
|
|
A [[id:1a74e6c8-023d-4a04-aae7-74d4428f6de5][Software Architecture]] consisting of multiple independant pieces of software
|
|
coordinating via message passing.
|
|
|
|
* A "Monolithic" Web application as a distributed system
|
|
|
|
A monolith presents itself as a single black box with no external dependencies or race conditions to contend with. But, is it?
|
|
|
|
- There's probably some sort of database to store state.
|
|
- If it's a web application, its clients are distributed!
|
|
|
|
#+begin_src plantuml :file distributed-web-application.svg :exports results
|
|
actor Browser
|
|
participant WebApp
|
|
database Database
|
|
|
|
Browser -> WebApp : Request Page
|
|
WebApp -> Database : Load Data
|
|
Database -> WebApp : Return Data
|
|
WebApp -> Browser : Render Page
|
|
...
|
|
Browser -> WebApp : Save Form
|
|
WebApp -> Database : Write Data
|
|
Database -> WebApp : Data Stored
|
|
WebApp -> Browser : Done!
|
|
#+end_src
|
|
|
|
#+RESULTS:
|
|
[[file:distributed-web-application.svg]]
|
|
|
|
- Myths
|
|
+ The database is local, therefore the connection is guaranteed to be fast and
|
|
stable.
|
|
+ Data is isolated to the user accessing it, there's no possibility for race
|
|
conditions / having to merge data.
|
|
+ The behavior of one user won't affect the experience of another.
|
|
- Any one of those lines of communication could fail for some reason
|
|
+ Bad request :: Something the user sent could cause an error
|
|
+ Bad state :: A service could be in a bad state and fail to react as
|
|
expected. The web server or database may be overloaded. Invalid data could
|
|
be persisted, breaking further requests.
|
|
+ Network issues :: Even on the same host, the other service could be down or
|
|
inaccessible.
|
|
- Any of those activities could occur /concurrently/
|
|
+ What happens when two different users try to save changes to the same data?
|
|
Or the same user, from two different clients or browser tabs?
|
|
* [[id:6f95b295-d872-4ba6-affc-19b8ad5e4717][Process Isolation]]
|
|
- Monolith vs. Services
|
|
|
|
* [[id:8ad5f29c-f967-4e36-b37a-22c309988df7][Concurrent and Parallel Programming]]
|
|
|
|
#+begin_quote
|
|
A system is said to be concurrent if it can support two or more actions in
|
|
progress at the same time. A system is said to be parallel if it can support two
|
|
or more actions executing simultaneously.
|
|
|
|
-- Clay Breshears, The Art Of Concurrency
|
|
#+end_quote
|
|
|
|
- Parallel :: Occurring at the same time
|
|
- Concurrent :: Occuring independently
|
|
|
|
Python threads are concurrent, but not parallel (execution is serialized,
|
|
contending for access to the Global Interpreter Lock).
|
|
* [[id:de3ac4c8-2648-410a-b8ed-088f33890781][CAP Theorem]]
|
|
|
|
[[file:data/e3/98cb62-2f26-46e5-ae00-64260adc4c43/Visualization-of-CAP-theorem.png]]
|
|
|
|
#+begin_quote
|
|
CAP is frequently misunderstood as if one has to choose to abandon one of the
|
|
three guarantees at all times. In fact, the choice is really between consistency
|
|
and availability only when a network partition or failure happens; at all other
|
|
times, no trade-off has to be made.
|
|
#+end_quote
|
|
|
|
Not absolutist, there are trade-offs that can be made to achieve a best possible
|
|
outcome.
|
|
|
|
* [[id:1ef99d1b-618b-41dd-afb7-0023d4e4481c][CRDTs]]
|