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.
oh, i was not aware that there is a head first just about desgin patterns, thanks for the heads up.
And Archicture is something that gets more and more important for devs, because it's likely that the code we write is just a part of a complex system of which we don't control every part and understanding communication channels and the reasoning behind the setup of the system allows us to write our part in a way that it works well in the bigger thing and not something others (or worse, we) have to work around later.
Refactoring by Martin Fowler, having patterns to help identify parts of code that could be changed for the better helps a lot.
Test-Driven Development with Python, because testing is important and you should atleast have tests in mind when writing you code, even if you dont write them first. I like this one, because it's very hands-on.
Head first java by Sierra and Bates, good introduction to programming with languages that offer object orientation and not as dry as the gang of four book, but definitely aimed at beginners
Fundamentals of Software Architecture by Richards and Ford, working as a programmer often means talking with big picture people or being one yourself, and they have their own strange language.
Domain Driven Design by Evans, for a similiar reason as Fundamentals of Software Architecture.
Neuromancer by William Gibson, because fun is important ;)
they were not sure if people(players and devs) would utilize the analogstick and chose to design the controller in a way that it could be used in the same way established controllers were used, the n64 predates the dualshock by a whole year afterall.
Dunstabzugshaubitze @ Dunstabzugshaubitze @feddit.org Posts 1Comments 140Joined 1 yr. ago
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.
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.
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.