[bgar]

Are you sure you’re specifically interested in Raft/Paxos/consensus algorithms? Distributed systems is more general than that. A lot of software engineers working on cloud services are basically doing distributed systems, if they are building multiple interconnected services. Where I work, our team has 10-15 services that communicate with each other, with databases, caches, and with other dependencies/consumers. This could also be considered distributed systems.

[zffr]

I'm more interested in the general problem of building those interconnected services, figuring out how to verify correctness, and scaling them to service the traffic they get. I think consensus might be a part of that (maybe for garbage collection?), but it's not something I'm specifically interested in.

[bgar]

Right. Then it might be worth applying to cloud software engineer roles in general, and be sure to ask your interviewers about what sort of architecture they work on. In your case, seems like you’ll be more keen to work on those teams that have multiple services, not those that have monoliths.

[throw51319]

Distributed would basically mean that a good portion of the core logic of the system is executed across multiple entities. So it can be scaled by simply adding more nodes. This is a specific niche, and engineers gain experience in that specific area. Am i right?

[bgar]

Kind of? I mean, if you’re working on an infrastructure or platform team, and building some distributed database or data pipeline, that would be more “distributed systems”, in the strict definition of the term. However, I doubt there are very many teams working on these sorts of problems —- it’s a very specific niche.

Edit: I might have misinterpreted your comment. The actual architecture of scaling by adding more hosts is quite common, if you’re processing independent messages.