How Uploadcare Built a Stack That Handles 350M File API Requests per Day
1–10 of 42 posts
Re: How Uploadcare Built a Stack That Handles 350M File API Requests per Day
#2Re: How Uploadcare Built a Stack That Handles 350M File API Requests per Day
#3Re: How Uploadcare Built a Stack That Handles 350M File API Requests per Day
#4All I can say is they don't seem to donate Django project.
Re: How Uploadcare Built a Stack That Handles 350M File API Requests per Day
#5All I can say is they don't seem to donate Django project.
Re: How Uploadcare Built a Stack That Handles 350M File API Requests per Day
#6I find it interesting that these sorts of stacks have tons of moving parts. Maybe it's the nature of highly scalable systems? Or does it come from starting with one particular technology and then having to drag in lots of other things to make it work?
Furthermore, to get high scalability, you have to make things as loosely coupled as possible. This means you're up to making some choices.
Hope that makes sense and answers the question :)
Re: How Uploadcare Built a Stack That Handles 350M File API Requests per Day
#7Re: How Uploadcare Built a Stack That Handles 350M File API Requests per Day
#8350M/day = just about 4K QPS. Is that considered impressive nowadays?
4k qps of DNS, for example, would be less interesting.
Re: How Uploadcare Built a Stack That Handles 350M File API Requests per Day
#9350M/day = just about 4K QPS. Is that considered impressive nowadays?
Assuming most transactions are a largish file transfer it seems impressive. And I assume the transactions aren't evenly spaced, so the peak is likely much higher. 4k qps of DNS, for example, would be less interesting.