Easiest way to tell whether it's worth it or not is to run some back of the envelope math on how much it'll cost to build and run (dev time + infra costs) vs relying on 3rd party.
5-10k seems like a low enough volume for 3rd party to be a good idea.
When you get to the high hundred thousands (let alone millions or tens of millions) it becomes prohibitively expensive to not roll in your own system.
You're missing the most important point of the entire Throttler goal: gracefully returning fast, with success or failure. Nowhere is it stated that the goal is to enqueue tasks for execution.
If you had read 'til the end you would have found multiple statements that OSAtomic* is merely an alternative. Not a silver bullet. Not the fastest.
From the conclusion:
"It's very important to understand that every example in this article could have legitimately been solved with different concurrency primitives — like semaphores and locks — without any noticeable impact to a human playing around with your app."
Also, "(...) is always going to be best executed, quickest, using GCD." is kind of a blanket statement. I'd be careful around the use of "always".
The goal of the article isn't about sheer performance — there are plenty of notes about it. If it was about pure performance, it'd be recommending moving away from objc classes and methods and using C functions or C++ classes instead, like std::atomic<>.
It's meant to be a somewhat-easy-to-digest introduction to lock-free design, where applicable.
It's not a design vs engineering boundary; it's a competence boundary. Your boundary simply encompasses more knowledge, of more areas — and thus you don't fit the archetype the article talks about.
Thanks! This gem looks interesting but doesn't apply here since with Jekyll you're basically serving static html pages (hence the need to make the A/B split with JavaScript).
It's not really the same as Dropbox. Dropbox is all about file synchronization and Droplr is about file sharing. Drag a file, get a tiny link to the content.
You can get the same with Dropbox but with a lot more interactions, so it kinda breaks the work flow.
You did establish a good point with placing the photos/binary objects on separate tables, but take for instance the Contact/AddressBook example: almost 100% of the times I'm fetching a Contact from the database, I also want the picture to serve it to a client, so putting it on a separate table would force the RDBMS to an avoidable extra effort.
My DB spiritual advisor tells me the rule of thumb is <= 500KB -> DB, > 500KB -> filesystem. I'll have to test performance of storing the binary stuff outside of the DB.
PS: By "truckloads" I mean tables with anything over 10 fields. I hate god tables/objects :)