this post was submitted on 23 Dec 2025
31 points (97.0% liked)
Programming
24030 readers
308 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
When designing large, complex systems, you try to break things down into manageable chunks. For example, the bit that deals with user login or authentication. The payment bit. Something that needs to happen periodically. That sort of thing.
Before you know it, there are tens, or hundreds of chunks, each talking to each other or getting triggered when something happens. Problem is, how do these bits share data with each other. You can copy all the data between each chunk, but that's not very time efficient. And if something goes wrong, you end up with a mess of inconsistent data everywhere.
So what bits of data do you keep in a shared place? What gets copied around from place to place? And what gets only used for that one function to get the job done? This is the job of software architects to sort out.
The author says the more copies of something you make, the more complexity and 'state' management you have to deal with. He's right, but there are ways to mitigate the problem.