roam/20210323005824-distributed_...

3.1 KiB
Raw Permalink Blame History

Distributed Systems

A 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!

/correlr/roam/media/branch/main/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?

Process Isolation

  • Monolith vs. Services

Concurrent and Parallel Programming

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

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).

CAP Theorem

/correlr/roam/media/branch/main/data/e3/98cb62-2f26-46e5-ae00-64260adc4c43/Visualization-of-CAP-theorem.png

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.

Not absolutist, there are trade-offs that can be made to achieve a best possible outcome.