Asynchronous by default, synchronous when necessary

Tomasz Nurkiewicz | @tnurkiewicz |


tl;dr: distributed systems & event sourcing

THE monolith

Splitting the monolith

1. All teams will henceforth expose their data and functionality through service interfaces.
4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
Jeff Bezos, CEO of Amazon, 2002

Amazon architecture circa 2009 Ebola virus

Amazon architecture circa 2009 Ebola virus

Amazon internal services architecture circa 2009

Steve Yegge (2005)

[Amazon's] code base is a disaster, with no engineering standards whatsoever except what individual teams choose to put in place [...]

Steve Yegge (cont.)

- pager escalation gets way harder[...]

Steve Yegge (cont.)

- very serious quotas and throttling [...] in every single service

Steve Yegge (cont.)

- monitoring and QA are the same thing[...]

Steve Yegge (cont.)

- you won't be able to find any [service] without a service-discovery mechanism

Steve Yegge (cont.)

- debugging problems with someone else's code gets a LOT harder

Turning Java interfaces to RESTful services

Cheap and safe

						long triple(long x) {
						  return x * 3;


						@RequestLine("GET /triple/{x}")
						long triple(@Param("x") long x);

						> GET /triple/13 HTTP/1.1
						> Host:

						< HTTP/1.1 200 OK

						< 39

Fallacies of distributed computing



1. The network is reliable

2. Latency is zero

3. Bandwidth is infinite

Batching, compression

4. The network is secure

SSL, OAuth

6. There is one administrator

Escalation, root cause

7. Transport cost is zero

The Internet is running in debug mode
Rüdiger Möller

Hollywood principle

...on architecture level

Synchronous architecture

Still synchronous

						    portfolio.fetch(LocalDate.of(25, JANUARY, 2017)),
						    risk.check("IBM", 12, -0.1, 0)

Scott Bellware:

One of the golden rules of service architecture is that you cannot query data from a service.
If you allow queries, you’ve [...] violated the most fundamental tenants of building a service, which is you tell a service what to do [...] (20:30)

Publish changes

Temporal coupling

Event DB

Audit, historic data

						GET /portfolio?at=25-01-2017

Synchronous architecture

Audit, historic data

						GET /portfolio?at=25-01-2017

Occasionally connected devices

Google Docs, Trello, Pocket, Evernote, Endomondo

Use case: blockchain

Use case: banking

"Banking": the hipster way

By sending thousands of simultaneous requests, the attacker was able to "move" coins from one user account to another until the sending account was overdrawn, before balances were updated

What went wrong?

No audit data


Race conditions

Academic approach

							-- Make sure no overdraft on Alice's account

							UPDATE accounts SET balance = balance - 100.00
							    WHERE name = 'Alice';

							UPDATE accounts SET balance = balance + 100.00
							    WHERE name = 'Bob';

Banking: real approach

SWIFT [...] providing a secure, reliable, and scalable network for the smooth movement of messages


					// ...
						from = 'Alice',
						to = 'Bob',
						amount = 100.0
					// ...

Full stack...

Atwood's Law

any application that can be written in JavaScript, will eventually be written in JavaScript

Use case: Redux


						function counter(state = 0, action) {
						  switch (action.type) {
						    case 'INCREMENT':
						      return state + 1
						    case 'DECREMENT':
						      return state - 1
						      return state

Event store implementation


Eventual consistency

Rebuilding costs


Can WWW work this way?

What's next?

Thank you!

Tomasz Nurkiewicz | @tnurkiewicz |