Ryan Peterman

Yeah, when I was reading about this migration, I saw somewhere in the migration, you initially started with Go, and then the racks or something that you're running on the hardware itself was ooming too much or requesting too much memory.

And then you migrated to Rust.

The cascading failure you mentioned, was there... So that happened and then there was a postmortem.

I don't think we needed a postmortem.

When I worked on infrastructure at Instagram, we had this concept of DEFCON knobs, which are basically these configs that you could flip that would gracefully degrade your system, where you can still operate it, but maybe in the case of Dropbox, you store less replicas.

So you take on a temporary increase of risk in losing data because you need to.

Did you have something like that and did you flip it in that type of case never when it came to durability?

I see.

So S3 is kind of, um, it's like elastic storage.

When I looked at this project, it's such a massive migration.

And my first thought is how do you coordinate this whole project without breaking the system as it's running?

What are your thoughts on doing such a large migration without breaking things?

Okay, so it was double writing both systems for a while.

Okay, and then you switched over Reed's

You mentioned simplicity, and intuition-wise, it makes sense.

Do you have a concrete example, though?

And I agree with you.

I think it's the long-term beneficial thing to do.

One unusual thing, though, in the industry that I've seen is the incentive system for engineers is actually, I mean, you mentioned the desire for an engineer to want to be seen that they can do something difficult.

There's that, but there's also the incentive system of promotions.