Data Intensive Ch4 - Encoding and Evolution

Question 1

Rolling upgrades

Answer 1

AKA Zero downtime deployment

Many small releases/deploys over few large ones
Easier to detect a change that introduces bug
Easier to roll it back
Support evolvability driver

Requires data backward/forward compatibility
When rolling out and back there is a window when 2 app versions are running in parallel

Question 2

Backward/forward compatibility

Answer 2

NEW code can read OLD data
OLD code can read NEW data
Applicable:
- if rolling upgrades are desirable
- client-side apps with no remote way of enforcing an update 

Usually forward is harder as new code must ignore extra data (so this must be thought of before going live)

Question 3

Data outlives the code

Answer 3

Code deploy replaces old version within couple minutes
Content of database remains relevant for years
Data migration is possible but it’s expensive if dataset grew large

Question 4

REST vs SOAP

Answer 4

REST is a philosopy, guidelines of web api design
based heavily on HTTP
SOAP is based on passing XML envelopes over SOME protocol (usually http too) but tries to remain independent from details of some given protocol
That means no facilitation of HTTP return codes, methods etc

SOAP comes with set of standards like WSDL - web service description language, each service registers itself with some description
The description enables clients to use code auto-gen tools for communicating

SOAP is PITA unless language and framework supports it off-the-shelf

Question 5

RPC

Answer 5

Remote procedure call
Pseudo-location-transparent call to remote service which looks like calling a method on local-memory-available object
It’s delusional because:
- local call has low execution time variance, RPC has not
- local call is 100% deterministic, RPC is not - request or response can and will get lost or timeout
- local call is always success/fail; RPC - sometimes it cannot be told and retry and idempotency must be employed.
Retry is needed as we don’t know if request got lost or just response. Idempotency is mandatory on service side so already processed requests can be safely repeated with the same result.
- local call uses object references so large objects are not a biggie;
RPC sends objects over the network so must encode them into byte format which, for larger objects, will become an overhead
- RPC parties can be heterogenous running different languages - data passed from one service may not parse in another… translation might be required

Question 6

Actor model

Answer 6

Programming model targeted for concurrency in a single process
Actor encapsulates logic and represents single unit/entitiy/client/document (with given id for example)
Actors usually have independent state
Actors can pass messages between them
Each actor processes SINGLE message at the same time
Actors can be scheduled independently in thread pool by actor framework