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

111–120 of 157 posts

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

#111

Post by mrkeen »

zellyn wrote: post #72

sewen (et al) This is lovely and I'm itching to try it. One question: We have a use case where a location gets cut off completely from the internet at large. In that case, it makes sense for the local hardware (typically Android and/or iOS tablets or equivalent) to take over as a log owner: even though you're cut off, if you're willing to swallow the risk (and hence cost) of offline payments, you should be able to cr…

> One could also imagine ensuring that > n/2 consensus members are always located inside the restaurant/hardware store/etc.

If the simple-majority is inside the restaurant, then the restaurant is online and the rest of the world is offline.

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

#112

Post by nyrikki »

withinboredom wrote: post #96
globular-toast wrote: post #94

Earlier quoted context omitted.

> It’s curious that over those projections, we then build event stores for CQRS/ES systems, ledgers etc, with their own projections mediated by application code. The database only supports CRUD. So while the CDC stream is the truth, it's very low level. We build higher-level event types (as in event sourcing) for the same reason we build any higher-level abstraction: it gives us a language in which to talk about busi…

I'm sorry; but have you ever actually used a database before? A database supports FAR more than "only CRUD". Some really simple examples are CTEs, SELECT ... INTO (or INSERT ... SELECT for some dialects), triggers, views, etc.

CTE's are extensions to try an regain some of what was lost when adopting a model loosely based on Codd's declarative relational algebra, specifically the lack of transitive closure, the rest mostly fit into the CRUD world.

It is a bit circular, CRUD's elements create, read, update, and delete were chosen to represent the core features of a persistence layer.

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

#113

Post by slt2021 »

withinboredom wrote: post #96
globular-toast wrote: post #94

Earlier quoted context omitted.

> It’s curious that over those projections, we then build event stores for CQRS/ES systems, ledgers etc, with their own projections mediated by application code. The database only supports CRUD. So while the CDC stream is the truth, it's very low level. We build higher-level event types (as in event sourcing) for the same reason we build any higher-level abstraction: it gives us a language in which to talk about busi…

I'm sorry; but have you ever actually used a database before? A database supports FAR more than "only CRUD". Some really simple examples are CTEs, SELECT ... INTO (or INSERT ... SELECT for some dialects), triggers, views, etc.

what you mention is a high level projection over transaction log and is subject to transaction isolation levels

https://www.postgresql.org/docs/current/transaction-iso.html

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

#115

Post by random3 »

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…

if order does not matter how do you implement deletes?

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

#119

Post by hinkley »

withinboredom wrote: post #101
hinkley wrote: post #90

Earlier quoted context omitted.

When I was in school I had an optional requirement. You had to take one out of 2 or 3 classes to graduate. That was compiler design, which was getting terrible reviews from my peers who were taking it the semester before me, or distributed computing. Might have been a third but if so it was unmemorable. So I took distributed computing. Which ended up being one of the four classes that satisfied the 80/20 rule for my…

So many people I work with don't "get" distributed systems and how they interplay and cause problems. Most people don't even know that the ORDER you take potentially competing (distributed) locks even matters -- which is super important if you have different teams taking the same locks in different services! The article is well written, but they still have a lot of problems to solve.

I went too far the other way. Concurrent things just fit my brain so well that I created systems that made my coworkers have to ask for help. One that still sticks in my mind after all these years wanted to ask me to knock it off but lacked the technical chops to make it a demand. But I could read between the lines. He was part of my process of coming around to interpreting all questions as feedback.

There’s about 20% of reasonable designs that get you 80% of your potential, and I’m a world with multiple unrelated work loads running in parallel, most incidental inefficiencies are papered over by multitasking.

The problem is that cloud computing is actively flouting a lot of this knowledge and then charging us a premium for pretending that a bunch of the Fallacies don’t exist. The hangover is going to be spectacular when it hits.

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

#120

Post by WilcoKruijer »

zellyn wrote: post #72

sewen (et al) This is lovely and I'm itching to try it. One question: We have a use case where a location gets cut off completely from the internet at large. In that case, it makes sense for the local hardware (typically Android and/or iOS tablets or equivalent) to take over as a log owner: even though you're cut off, if you're willing to swallow the risk (and hence cost) of offline payments, you should be able to cr…

Interesting use case, I've also thought about this in the past.

I wonder why you want to designate the local device as "owner". The devices could simply keep the (closed) payments in a local outbox, and send them to the server when it comes back online. If there is no way for syncing the local changes to the server to fail, you've essentially created a CRDT (at least the "conflict-free" part).

Of course that means you cannot have any server side validation at all (maybe this is what you mean by "owner"?). Because that would mean closed out payments would be rejected by the server and you'd end up in an inconsistent state. A consequence of this is that there could be no balance checking (as an example). Payments in a ledger are inherently a CRDT!

The consensus part is interesting. Would you really need it? Wouldn't one device be sufficient to validate a transaction? And would consensus really even mean something within a small building? If the restaurant catches on fire the data would be lost anyway, so if you don't achieve "high-availability", why bother?

Post reply on HN