> hence you need to query _all_ the nodes or can end up in a split-brain situation and lose consistency
I am not sure this is true. It is prohibitively expensive to read from all replicas. All you need to ensure is that any replica has the latest state. See how Azure Storage does it [0]. Another example is Spanner [1] that uses timestamps and not consensus for consistent reads.
Absolutely, the vast majority (95%+) of logs are never read by a human. Therefore, processing it is enormously wasteful. A good architecture will write once and not touch anything until it is needed.
I spent years working on system handling 50+PB/day of logs. No database or ELK can handle that, and even if it did it would be prohibitively expensive.
> Expect at minimum 2 Medium difficulty questions in a phone interview that need to be able to be solved in optimal space time complexity in under 45 mins
I see this being repeated on Leetcode and Blind, but it is not my experience at all.
In 2019, I got Senior level (L5/E5) offers from everywhere I applied, including Facebook and Google. I never solved more than a single medium problem in 45m-1h. I was asked a hard problem maybe twice, and not at FB & G.
I also interviewed 100+ candidates at Microsoft and Google. I have seen hundreds of interview questions and feedback reports and I simply can't corroborate that statement.
> Standing is denser than walking, so the throughput is greater
Doesn't this depend on the walking/standing density ratio and walking speed/escalator speed ratio?
Let say the walking density is 1/2 of the standing density. If the walkers walk at the speed of the escalator (i.e. their speed relative to the ground is 2x the speed of the escalator), then the throughput is the same.
A DCT (Dual Clutch Transmission) like the Porsche PDK is not remotely comparable to a torque converter based transmission. Yet, both are categorized as "automatic".
Disclaimer: I work at Microsoft, not on Service Fabric but I have built complex stateful services on top of Service Fabric.
As zapita said, Service Fabric now handles containers but I think it is just because containers became trendy and FOMO kicked in.
Where Service Fabric is decades ahead of the container orchestration solutions is as a framework to build truly stateful services, meaning the state is entirely managed by your code through SF, not externalized in a remote disk, Redis, some DB, etc...
It offers high level primitives like reliable collections [0], as well as very low level primitives like a replicated log to implement custom replication between replicas [1]. I feel that publicly this is not advertised enough and it is unfortunate because it is a key differentiator for Service Fabric that the competitors won't have for a while, if ever because it is a completely opposite approach: containers are all about isolation, being self-contained and plateform independent while SF stateful services are deeply integrated with Service Fabric.
The first thing I was asked when I interviewed with Microsoft was what I wanted to do and what I wanted to avoid. I said, no frontend, something related to distributed systems and they put me up for interviews with an Azure team.
With Google, it was like "interview first, accept the offer before knowing where you are going to be placed, and we will put you in some team".
> But regular expression, to be honest, is usually something I hardly think about performance.
This is actually not an uncommon problem. I recently experienced a backend system going down because of catastrophic backtracking. There is a reason why proper regex libraries have a timeout on the match methods.
Try to find out if your employer or your university has a partnership with a local bank.
I was able to open an account and get a credit card with a $10k spending limit with only my passport, less than 24h after landing in the U.S. for the first time.
In my experience, CPU is rarely the big issue when dealing with a lot of data (I am talking about tens of PB per day). IO is the main problem and designing systems that move the least amount of data is the real challenge.
I grew up in France, which has more than 50% of the world's roundabouts. They are everywhere.
Where I am from, there is a roundabout at the intersection of a major road and a small road with little traffic. During rush hour, it is impossible to enter the roundabout coming from the small road because there is a continuous flow of cars coming from the major road. It is truly an uninterrupted flow of cars because the cars come from another roundabout...
Before the roundabout, there was no problem because there was a light that would be always be green for the main road expect when a car was detected on the small road. It was optimal.
The fact that most of Europe is in the same timezone is disturbing.
I remember visiting Budapest (East of the timezone), coming from Bordeaux (West of the timezone), and noticing how much earlier (1h30) dusk was.
I wonder if it has an impact on the mood of the inhabitants.
Absolutely. "Stack" in "Full-stack" always seems to refer to a Web stack where the back-end is a database, a framework and maybe a service such as ElasticSearch or Redis.
I might be biased but to me, this is web development, not back-end. Back-end is designing distributed systems, data pipelines, trading systems, databases, etc... It has nothing to do with Web development.
I am not sure this is true. It is prohibitively expensive to read from all replicas. All you need to ensure is that any replica has the latest state. See how Azure Storage does it [0]. Another example is Spanner [1] that uses timestamps and not consensus for consistent reads.
[0] https://sigops.org/s/conferences/sosp/2011/current/2011-Casc... [1] https://cloud.google.com/spanner/docs/whitepapers/life-of-re...