About System Design

05/08/23 • 38 min

Did they do design, or did they just do a system?

Distributed systems are hard in many ways. Andreas describes a system communicating between backends and mobile phones in exciting ways with many exciting possibilities for errors. Like data format changes, loss of messages, having 1.5 source of truths, and of course ordering.

In certain cases, nobody likes an optimist.

The discussion then moves to discuss the working well-windows for various networking solutions, before diving into WebRTC and finishing up with the various dangers of auto.

Links

Recursion
Eventual consistency
Pubsub
RethinkDB
Event sourcing
React native
Android studio
Mnesia - a "distributed, soft real-time database management system" written in Erlang
Dirty reads and writes
Websockets
QUIC
UDP
TCP
WebRTC
NAT
HTTP live streaming
Lars' ElixirConf talk
Zoom H4
Zoom H4n pro

Quotes

Working with systems and feeling the pain
Coping with system design
Eventually consistent, on a good day
Eventually sourced
A disappointment to work with
Your internal representation of the user
This is the shape of the data, deal with it
1.5 source of thruths
Oh, it's an optimist
I don't like optimists at all
Optimist databases
Within its working well-window
Outside of the working well-window
A crash of servers
Bad connections over long distances
I don't do math

Did they do design, or did they just do a system?

In certain cases, nobody likes an optimist.

The discussion then moves to discuss the working well-windows for various networking solutions, before diving into WebRTC and finishing up with the various dangers of auto.

Links

Recursion
Eventual consistency
Pubsub
RethinkDB
Event sourcing
React native
Android studio
Mnesia - a "distributed, soft real-time database management system" written in Erlang
Dirty reads and writes
Websockets
QUIC
UDP
TCP
WebRTC
NAT
HTTP live streaming
Lars' ElixirConf talk
Zoom H4
Zoom H4n pro

Quotes

Working with systems and feeling the pain
Coping with system design
Eventually consistent, on a good day
Eventually sourced
A disappointment to work with
Your internal representation of the user
This is the shape of the data, deal with it
1.5 source of thruths
Oh, it's an optimist
I don't like optimists at all
Optimist databases
Within its working well-window
Outside of the working well-window
A crash of servers
Bad connections over long distances
I don't do math

Previous Episode

About Conferences

Lars went to ElixirConf EU. Going to a conference can be a credibly incredible experience. Elixir has more clarity than Erlang.

Lars also gave a talk, a fact he was comfortably uncomfortable with. Giving a talk also comes with benefits such as being able to talk to fish in a barrel. But why did he choose to make the whole talk a demo? What is the goal of it all?

Gotta build things! Dive in, make stuff.

Links

ElixirConf EU
Lars' conference report blog post
Code BEAM
Sverok
Pieter Hintjens about giving talks by talking to the audience
Windows 98 (not 95) demo fail
Lars' presentation code
Voice Driven Development: Who needs a keyboard anyway? - presentation by Emily Shea
Hugging Face

Quotes

Born during ElixirConf
Less clarity to it
Genservers and stuff
Mainstream Elixir
Comfortable with that discomfort
Talking to fish in a barrel
A buddy from the internet
The first one I bothered to count
Your loose coupling to anything
What do you hypothetically know?

Next Episode

About Developing Speed

CTOs want the ability to get prototypes built and out into production fast. Others preach the gospel of building things properly. How fast can you be? How much can you perpare before you hit the ice? And one you built and shipped that prototype, how can you get any kind of speed trying to maintain and evolve something where many corners were cut for speed?

How do we want things to work then? Having an algebra for things might be nice. A sprinkling of interface, things that break noisily, and nice toolboxes to work with structs are all discussed.

Links