HN user
Roughly the angular reolution of a telescope is 1.22*wavelength/diameter. See https://en.wikipedia.org/wiki/Angular_resolution. Hubble uses visual light (0.5 um wavelength) while JWST uses IR (5 um wavelength) and beyond. So the wavelength for JWST is 10x larger than Hibble, but the diameter is only ~2.7X (Hubble 2.4m vs JWST 6.5m dia). So JWST resolution is 1.8x worse than Hubble.
Is it really that important that the time to get to 200 should be small? I understand that it may be frustrating to get started, but assuming I am stuck to this API for a long time, I am lot more worried about stability, quality, performance and availability of the system than time to onboard.
Basically if you want to replicate data across multiple nodes, all of them need to agree on the sequence of data updates. For example if I did [x=6, x=7], then the outcome of those ops is very different if I did it in the opposite order [x=7, x=6]. Easiest way to do this sequencing is to have a unique leader who will impose the unique order. Strict sequencing is not really serializability, but linearizability. For example, Cassandra doesn't by default have the concept of a leader and hence can't provide linearizability. Of course, there is a problem on how you decide who is the leader and what happens if two nodes think they are the leader at the same time. That's where the genius of Multi-Paxos/Raft comes in. You can read more about sequencing here
https://medium.com/swlh/replication-and-linearizability-in-d...
Consistent hashing is a routing algorithm, not a consensus algorithm.
Zookeeper is the standard one which has been around the oldest. Zookeeper is not based on raft, but it has similar semantics as etcd. So if you don't care about the impl, ZK may be good as well.
Oracle cloud is quite a thing. It's in 4th place behind AWS, Azure and GCP and has significant presence. For example zoom is a big customer:https://www.lastweekinaws.com/blog/why-zoom-chose-oracle-clo.... I assume under the new tiktok deal, tiktok might run on the Oracle cloud.
The author's advice is country dependent. My assumption is that he is writing from the perspective of buying in India.
1) In India, rents are very low compared to mortgage payments. 2) Home value appreciation is low given the rate of inflation. 3) financial instruments like home equity line of credit are not available.
So yes, it probably is not a good decision to buy a house in a big city in India. Elsewhere? Do your own calculation.
There are some painpoints that are being addressed:
1) timestamp : I have had issues with a round-tripping timestamp representation quite a bit 2) decimal : currency is denoted in decimal rather than float and shows the Amazon retail heritage. This is very useful. 3) symbols : I've had cases where symbol table/dictionary would have made big difference in serialized size