Stripe seems to have set things up to use a different ivy cache for each user, so every time you deployed code it had to redownload all of the dependencies. Th

Stripe seems to have set things up to use a different ivy cache for each user, so every time you deployed code it had to redownload all of the dependencies. Thank you. So normally you'd have the dependencies prebuilt, and it wouldn't take long at all to deploy? That sounds more sane. The build time for golang was < 1 second for comparison, and at first I couldn't get rid of the sbt build due to confusion over start_server/start_servers being used to launch, which was a bit annoying. I couldn't get their solution to build locally so I just gave up on Scala, which is a shame, perhaps I'll try again sometime. l4 was pretty hard, even just integrating raft in the time available, I started adapting what they had, then switched to inserting raft - I was still left with some issues, and it was humbling and awesome to see people scoring so highly on it for me with things like in-memory dbs, but also great just to read about the problem space, which isn't one I'd normally touch at all. So an education even if you didn't pass, which was pretty chancy anyway in my experience. Note to Stripe: I would gladly pay $10 next time around if it could buy more/better ec2 instances. I wondered if that was part of the challenge, particularly on l3, it meant it was harder to solve with just one instance, but yes it did cause frustration, particularly because a working solution locally would then not work remotely and scores were all over the place, even for the same code, due to contention and the random tests loading remotely. It's probably really hard to set this stuff up, and I look forward to the infrastructure posts to see how they did it.