Good system design

Post by RaftPeople » Sat, Aug 16, 2025, 4:21 PM UTC

mrkeen wrote: post #55

maxbond wrote: post #25

Earlier quoted context omitted.

Audit tables are a big ask both in terms of programming effort to design and support them, and in terms of performance hit due to write amplification (all inserts and updates cause an additional write to an audit table). Whereas making a bool into a timestamp is free. Including timestamps on rows (including created_at and updated_at) are real bacon savers when you've deployed a bug and corrupted some rows and need to…

Audit tables are a dumb concept because they imply bolting on an actual source of truth in addition to the regular not so source of truth tables , and only if the programmer gets around to it (like documentation or logging or whatever else falls along the wayside).

Post by hk1337 » Sat, Aug 16, 2025, 4:24 PM UTC

mattmanser wrote: post #56

hk1337 wrote: post #46

Earlier quoted context omitted.

You should be careful with how much you lean into “doing it in the database” as well with how you implement it. Lest, you get the situation where your application inserts as one value and it gets saved completely different.

I'm not sure if this is what you mean, but I think a big thing missing from the article is how you should isolate you business logic. A great software design will separate all business logic into its own layer. That might be a distinct project, module, or namespace, depending on what your language supports. Keep business logic out of SQL and out of web server code (controllers, web helpers, middleware, etc.). Then yo…

Post by richardlblair » Sat, Aug 16, 2025, 4:25 PM UTC

wild_egg wrote: post #150

richardlblair wrote: post #89

Earlier quoted context omitted.

If your ORM is going to the DB per row you're using it wrong. N+1 queries are a performance killer. They are easy to spot in any modern APM. Rails makes this easy to avoid. Using `find_each` batches the queries (by 1,000 records at a time by default). Reading through the comment section on this has been interesting. Either lots of people using half baked ORMs, people who have little experience with an ORM, or both.

I mean Rails also makes it easy to accidentally nest further queries inside your `find_each` block and end up with the same problem. Your team can have rules and patterns in place to mitigate it but I'd never say "Rails makes this easy to avoid".

Post by stefanfisk » Sat, Aug 16, 2025, 4:31 PM UTC

santiagobasulto wrote: post #170

alixanderwang wrote: post #131

> I’m often alone on this. Engineers look at complex systems with many interesting parts and think “wow, a lot of system design is happening here!” In fact, a complex system usually reflects an absence of good design. For any job-hunters, it's important you forget this during interviews. In the past I've made the mistake of trying to convey this in system design interviews. Some hypothetical startup app > Interviewer…

I’ve been in software for 20 years and it’s the first time I hear “back pressure”. Am I too old already?

Post by Yokohiii » Sat, Aug 16, 2025, 4:32 PM UTC

marcosdumay wrote: post #217

Yokohiii wrote: post #121

Earlier quoted context omitted.

In my ears that's just neglect? You assume your ORM does the basic data mapping right and don't verify it?

> You assume your ORM does the basic data mapping right You know, it should. There's no good reason for an ORM to ever fail at runtime due to mapping problems instead of compile time or start time. (Except, of course if you change it during the software's execution.)