Chronicle-Map

t's reliable that you being to consider isolating instability as a top benefit from your IPC setup instead of a tiny value add... it might be a sign you're not ready for microservices. _ > True, sadly it doesn't usually work this way. People take the path of least resistance. > Also once you add multiple DBs you start to get into eventual consistency; which is one of the harder parts of microservices. You're making my point: If you don't have the engineering chops as a team to make a robust monolith, you definitely don't have the skills and resources to start looking at microservices. Eventual consistency is not inherent to having multiple databases. If I have an oft changing ephemeral set of data that only affects one feature and it's creating an impedance mismatch with our main datastore, nothing is stopping us from pulling in Redis for all the queries we were previously sending to Postgres, and as far as anything relying on that feature is concerned, nothing at all changed. With even half decent engineering, Redis going down doesn't break any differently than it would have for a microservice: you define the same error boundaries as before and the failure case ends up the same. I mean seriously, if your team can't handle having a second data store, imagine the bedlam when you're trying to handle multiple languages across multiple data sources in a non-centralized manner? _ Microservices are a pattern for companies where a "microservice" gets the kind of development and devops support that would justify spinning off a new mid-sized enterprise. When you're Netflix your `api/movies/[movieId]/subtitles` endpoint is serving the kind of traffic most companies will never see in their lifetime and needs optimizations that maybe 100 companies in the world will ever need. For the rest of us EC2 has 224C/488T CPU 24,000 GB RAM machines with 38 GBPs I/O bandwidth. If your business ever scales so far that you outgrow that, throw some of that X Billion dollar valuation money at the problem and build your microservices.

root, which in practice means grouping chunks together by which ones semantically have been determined to be part of the same base, then makes a report by quantity per base. There was also a web UI that showed all active tracks. You could click any player and see their travel history, the route they had taken to get to that location. As well as clicking any cluster and seeing the usernames associated with it. We used this a lot to grab what members were present at a given item stash or base, to make sure we weren't stepping on anyone's toes. In terms of what it took to make this happen, the stars of the show were probably the main Postgres, which was hand-tuned on top of a hand-tuned ZFS, on top of a NVME drive that was IOMMU passthrough'd to this VM for maximum performance. As well as https://github.com/OpenHFT/Chronicle-Map, which really helped out. We needed a mapping from block coordinate to a bit of data about that location, such as the last timestamp we checked it, what Minecraft block was there last, whether the block is interesting, uninteresting, different from seed, etc. High frequency trading software was perfect for this use case, because it greatly reduced GC pressure on the JVM, since the data was stored off-heap. It ended up at around (roughly) fifty million entries, served hundreds of thousands of requests for block data per second, and requested historical data (from the Postgres) at about thirty thousands SELECTs per second (from a table with over ten billion rows). The reason why this needed to be so fast, is that the use case is downloading bases. Sometimes someone would log in to 2b2t at their base, after having not played for weeks at a time (so the data is in Postgres, not the map in RAM), we wanted to be able to pick up right where we left off on downloading what they had built. This means it needs to get back up to speed with their entire base, as fast as possible, in the seconds before they move away to other chunks, or log off the server. We are downloading bases one click at a time, and bases are huge. The area that is loaded in by a player is 144 by 144 by 256. That’s 5 million blocks. And there are about 250 players online on 2b2t at any given moment in time. That’s well over a billion blocks that we could click on, and learn which Minecraft block they are. But, which locations should we use up our clicks per second budget on? It focused on areas that are being changed rapidly, and areas that are different from the base vanilla terrain. Those are certainly bases, large Minecraft builds. We do an expanding paintbucket pattern that expands in 3 dimensions to whatever has been built there. However, we have to do this quickly, and we have to pick up where we left off. Someone might be flying around their base with an elytra, at very fast speed. We would love to scoop up the terrain that they’re flying over. If the base is particularly interesting, someone flying over a certain area could have had about twenty Minecraft accounts spread all over 2b2t’s map suddenly refocus all of their left clicks on that one area, to grab all the interesting neighbors that it wasn’t able to last time. We peaked at about three thousand block clicks per second, averaged over weeks. So this was a massive data loading and management problem.