Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every System is a Log: Avoiding coordination in distributed applications

restate.dev

Post reply on HN
Print view View original

31–40 of 157 posts

Re: Every System is a Log: Avoiding coordination in distributed applications

#31

Post by grahamj »

jaseemabid wrote: post #12

A notable example of a large-scale app built with a very similar architecture is ATproto/Bluesky[1]. "ATProto for Distributed Systems Engineers" describes how updates from the users end up in their own small databases (called PDS) and then a replicated log. What we traditionally think of as an API server (called a view server in ATProto) is simply one among the many materializations of this log. I personally find thi…

Table/log duality goes back further than Kleppmann though. An earlier article that really influenced me was

https://engineering.linkedin.com/distributed-systems/log-wha...

Re: Every System is a Log: Avoiding coordination in distributed applications

#32

Post by clayg »

pjc50 wrote: post #25

> Having a single place (the one log) that forces a linear history of events as the ground truth and owns the decision of who can add to that ground truth, means we don’t have to coordinate much any more. Well, yes, but then you've backed into CAP again because you only have one log.

But can't any log be implemented as a CRDT? Was that not implied in the post? I didn't read it that close...

Re: Every System is a Log: Avoiding coordination in distributed applications

#33

Post by xnorswap »

It sounds like they have just re-discovered Distributed Transactions with a Distributed Transaction Coordinator.

But DTs have a huge problem: What happens if the owner of the lock netsplits?

Either the DTC waits (potentially forever?) for the owner of the lock to get back in touch and release the lock, or a timeout is applied and now the owner of the lock (who may be unaware of the netsplit) will be out of sync with the system.

Re: Every System is a Log: Avoiding coordination in distributed applications

#34

Post by log4shell »

trollbridge wrote: post #11

I’ve been doing a similar thing, although I called it “append only transaction ledgers”. Same idea as a log. A few principles: - The order of log entries does not matter. - Users of the log are peers. No client / server distinction. - When appending a log entry, you can send a copy of the append to all your peers. - You can ask your peers to refresh the latest log entries. - When creating a new entry, it is a very go…

Calling a WAL a ledger, why? Ledger sounds fancier but why would it be a ledger in this case?

Re: Every System is a Log: Avoiding coordination in distributed applications

#35

Post by mrkeen »

pjc50 wrote: post #25

> Having a single place (the one log) that forces a linear history of events as the ground truth and owns the decision of who can add to that ground truth, means we don’t have to coordinate much any more. Well, yes, but then you've backed into CAP again because you only have one log.

If I've understood it, it's like using Kafka with 1 topic and 1 partition. But it shouldn't rule out multiple brokers with a >1 replication factor, giving you CP.

Re: Every System is a Log: Avoiding coordination in distributed applications

#37

Post by kasey_junk »

hiAndrewQuinn wrote: post #36

I am a huge fan of append-only logs as a fundamental architectural principle. The Log [1] should be required reading for any CS undergraduate. [1]: https://engineering.linkedin.com/distributed-systems/log-wha...

I love them so much that I’ve noodled with building a programming language optimized for using them.

Things like types that encode what events are legal in a log, first class support for data versions, fast file read and writes, etc

Re: Every System is a Log: Avoiding coordination in distributed applications

#38

Post by clayg »

XorNot wrote: post #22
trollbridge wrote: post #11

I’ve been doing a similar thing, although I called it “append only transaction ledgers”. Same idea as a log. A few principles: - The order of log entries does not matter. - Users of the log are peers. No client / server distinction. - When appending a log entry, you can send a copy of the append to all your peers. - You can ask your peers to refresh the latest log entries. - When creating a new entry, it is a very go…

How do you know summary entries are valid if order doesn't matter? I.e. "we have 10 customers as of this date" can become immediately invalid if a new entry is appended afterwards with a date before that summary entry (i.e. because it was on a peer which hadn't yet sent it)

IME you have to be willing to recalculate the summaries up to some kind of consistency window.

Yes you may be changing history and you may have a business reason not to address that revision immediately (you've already billed them?) - but the system can still learn it made a mistake and fix it (add activity from Jan 30 evening that comes in late to the Feb bill?)

Re: Every System is a Log: Avoiding coordination in distributed applications

#39

Post by ismailmaj »

clayg wrote: post #32
pjc50 wrote: post #25

> Having a single place (the one log) that forces a linear history of events as the ground truth and owns the decision of who can add to that ground truth, means we don’t have to coordinate much any more. Well, yes, but then you've backed into CAP again because you only have one log.

But can't any log be implemented as a CRDT? Was that not implied in the post? I didn't read it that close...

CRDT is really only useful when inconsistencies could be acceptable in some situations and so it depends on the application.

For something that is trying to solve the general problem of consistent single ground-truth log, you can't really do much better than Spanner.

Re: Every System is a Log: Avoiding coordination in distributed applications

#40

Post by cduzz »

Kinrany wrote: post #23
trollbridge wrote: post #11

I’ve been doing a similar thing, although I called it “append only transaction ledgers”. Same idea as a log. A few principles: - The order of log entries does not matter. - Users of the log are peers. No client / server distinction. - When appending a log entry, you can send a copy of the append to all your peers. - You can ask your peers to refresh the latest log entries. - When creating a new entry, it is a very go…

> The order of log entries does not matter. This is surprising, Kafka-like logs are all strictly ordered.

* within a partition
Post reply on HN