3 ms·

Can you elaborate on 4 a bit, are you saying to always use event sourcing, or something like it?

• frollogaston 3mo ago
  Yes, it's that. You do probably end up wanting to store some "latest" denorm tables at some point, but it takes surprisingly long to reach that point, and isn't hard when you get there. There are disadvantages to this, but it's a safe default. The alternative is possibly losing important data, finding out later you want historical records of things that are stored in kludgy separate tables, getting into more advanced locking situations, and having more complex DB migrations. Which I've had to pull teams out of many times.
  • 0x696C6961 3mo ago
    Using event sourcing instead of basic crud should go on a startup suicide guide ...
    • atom_arranger 2mo ago
      I don’t have a lot of experience related to this so I’m just noting some things. Some people in this thread don’t seem to think it’s that hard or overcomplicated. When reading Designing Data-Intensive Applications my main takeaway was that event sourcing can make it easier to solve a lot of issues like performance, scaling, consistency, auditability, etc. It would be interesting to look into what a low overhead way of implementing CRUD with event sourcing in Postgres would look like, then decide if it’s too complex.
      • frollogaston 2mo ago
        Try making Hackernews lite. Users can post, comment on posts, vote/unvote posts, and delete their own posts and comments. CRUD tables might be post, comment, maybe vote. Event tables might be create_post, delete_post, create_comment, delete_comment, vote, unvote.
      • 0x696C6961 2mo ago
        Don't trust anyone who tells you event sourcing is simple to implement.