Hacker News new | ask | show | jobs
by mrkeen 501 days ago
> I worked with a feature that used this approach once.

You work with many features that use this approach.

  https://www.dbi-services.com/blog/oracle-log-writer-and-write-ahead-logging/
  https://git-scm.com/docs/git-reflog
  https://dev.mysql.com/blog-archive/mysql-8-0-new-lock-free-scalable-wal-design/
  https://www.postgresql.org/docs/current/wal-intro.html
  https://www.sqlite.org/wal.html
  https://www.amazon.science/blog/lessons-learned-from-10-years-of-dynamodb
1 comments
Izkata 501 days ago
From this:

> was cumbersome and extremely slow.

I'm pretty sure those sit somewhere in between the two sides GP was describing: All of your links have "current state" as the interface and changes are logged as they're applied. The system they worked with apparently has the log as a first-class citizen and no "current state" interface, while what they wanted was a "current state" interface with snapshots.

link
mrkeen 500 days ago
Understood, but when we look at all the databases and source-control products, we're standing on the customer side. We get to experience stuff that just works, because the people on the development side opted for write-AHEAD-log and/or copy-on-write, as opposed to write-afterward-log or write-but-store-backups-in-case-something-goes-wrong.

When we're on the developer side of things, we get to choose whether to CRUD or to go eventy. If we want to build systems as good as those DBs, we should do what they did (events) rather than what they say (insert/update/delete). It's unfortunate that there's not much upstream tech to help us with this (it's pretty much just kafka) and that people who choose to use kafka get accused of 'resume-driven-development', etc.

>> Querying current state, which was 99% of the usecases, was cumbersome and extremely slow.

It's an easy fix if the events are there. Just cache the current state. It sounds glib but it's one of the first-principles of event-sourcing that makes me choose it over CRUD. If your events are immutable, they can be shared. If they can be shared, they can be folded into a fast-current-state-view. If they are instead mutable (or non-existent)), you can't share them unless you also have a plan on how to sync them (which no-one gets around to and probably overlaps on some classical impossibility result like two-generals.)

link