seems like the problem is not well defined, because it might also be possible to drill a whole pigeon away, given a sufficient number of large enough holes.
yeah, thats still an open question, if i dont forget anything about s2.
i'd guess it will be some technobable about the video signal thats send to the cleaners helm and the cafeteria window are processed by the same programs, if they ever want to get back to it or it will be explained as some kind of fail-safe to get potential rebels out of the silo or something like that.
I have read about this related to how FB does it. In general this means that fetching from the DB and keep it in memory to work with right? So we assume that the cached data is outdated to some extend?
correct, introducing caching can result in returning outdated data for awhile, which is usually not a huge deal. those caches can get tricky, but they should take pressure from your db, if you're scenario is read heavy, which is often the case. Research existing caching solutions before running ahead and implementing something from scratch, especially if you need a cache distirbuted between multiple instances of your service. In the Java world that would be something like Infinispan, but your ecosystem might over better integration with other solutions.
I was able to convince management to put money into a new server (SSD thank god). So thank you for your emphasizes. We are also migrating to PostgreSQL from SQL server, and refactor the whole approach and design in general.
having management on board is great and the new hardware should help a lot, migrating to another RDBMS sounds scary, but probably worth it if your organisation has more expertise with it.
generate indexes
they won't help you with your duplicates, they will help speed up your reads but could slow down writes. building a good index is not trivial, but nothing is when it comes to performance tuning a database, it's tradeoff after tradeoff. The best way to handle identical rows of data is to not write them usually, but i don't know your system nor its history, maybe there is or was a good reason for its current state.
get the data needed by specific services into the service, only get the data from a central place if you have to (spinning up a new instance, another service changes state of data you need, which is a warning sign in itself that your architecture is brittle...)
faster storage/cpu/ram
generate indexes
2nd level cache shared between services
establish a faster datastore for often requested data thats used by multiple services (that might be something like redis, or another rdbms on beefier hardware)
gittea ltd was founded without adhering to the governance model gittea had and also claimed copyright on atleast the name and logo of gittea. many felt a non-profit would be a better way to organize development and thats how codeberg e.v. came to be.
the problem is not, and never was offering support and service against money, you can right now start selling forgejo if you'd desire to, it was allways about how the project itself should be organized.
https://kalpadesktop.org/ is basend on opensuse MicroOS, a distro with atomic updates. this comes with KDE, there is also a version with gnome of which i forgot the name.
seems like the problem is not well defined, because it might also be possible to drill a whole pigeon away, given a sufficient number of large enough holes.