The stuff we used Go for was the right choice for Go for sure, but I don't think the API would have been any easier in Go (though I haven't used those frameworks before...).
We also could have done Django a lot better. And all of the Celery stuff probably should have been Go, especially with the Cassandra driver we were using. Still, I'm using Django today and as long as you don't abuse the ORM and nested DRF serializers too much, it's very scalable. I think as long as you make separate services in other languages at the right time for the right use cases, it's a very valid choice for rapidly building an API.
50k seems like a low bar to start losing messages at. If this was done with Celery and a decently sized RabbitMQ box, I would expect it to get into the millions before problems started happening.
These machines do more than just push. They also buffer messages for each individual user to "potentially" push if they don't read them on the desktop client. This happens before the flow this article talks about.
We currently have 3 machines doing this for millions of concurrent users. At the writing of this article it was 2 machines.
What size machines are these? I'm shocked that this volume is your max handling with Erlang unless your using a smaller T series AWS instance for this.
These are getting easily over 30,000 requests a second each about updating queues for new messages. And also are subscribed to presence events from our presence system to millions of people. It is a very busy service ensuring we only deliver messages to people not at their computer.
So if they are delivering 30k a second per box and the max "backlog" you allow to build is ~50k, then you cap your backlog at under 2sec worth of delivery? Or am I missing something?
At some point, when a system has entered a failure mode for a while, it makes sense to start shedding load, rather than attempting to deliver every single push notification. Also worth mentioning, a minute of downtime is already a million backed up pushes. Beyond that, it becomes infeasible to attempt deliver them.
Edit: Also worth mentioning, the 50k buffer is for a single server, we run multiple push servers in the cluster.
At 15k notifications per minute, a million notifications would take 1hr to clear before the queue returns to normal. I would imagine they prefer to shed load early so notifications don't get delayed, hence the small buffer.
The issue was not the ability of their servers to handle the load, but the ability of Firebase to ingest the notifications - at least, that's how I read it.
> Of course you design it in such a way, that you can change one of the inputs, which will by definition invalidate the tokens.
I was looking at using JWT to avoid a database read when authenticating a request, but in order to get some sort of variable per-user value I'd have to hit the database to get it, no? Doesn't that kind of defeat the purpose?
Said variable could be in memory, but the point isn't to save DB reads, but to avoid saving data you don't need to. This is a technique to implement the same feature without having to store additional information in your core business logic, that is relatively useless outside of this password reset or user signup. Of course you may want to save this for BI of audit purposes, but then you can (and should) use an appropiate seperate system.
I imagine this working a lot like car2go, which I've used to commute in Austin. The cars are rarely at a central depot except for maintenance. They're left wherever you last used them until someone else gets in. This could only be better than that, as users won't have to walk to find one.
There's no reason for the cars to drive back into the city every evening. They could charge themselves while you're at work if they had to charge daily.
Is there a bug in the train function? Using 'lambda: 1' for the default dict along with '+=' means that the first time a feature is encountered, the value is set to 2.
In [1]: from collections import defaultdict
In [2]: d = defaultdict(lambda: 1)
In [3]: d['foo'] += 1
In [4]: d['foo']
Out[4]: 2
I think the code is correct. To implement smoothing, you want to add 1 to the count of every word, regardless of whether it appears in the training data or not.
That is to say, a word that appears once should get a count of 2, and word that doesn't appear at all should get a count of 1.
This is a perfect example of where a (short) code comment would be helpful. The "lambda: 1" a notable piece of code, but it's hard to tell that at a glance.
nonsense, any software dev that can't follow a lambda that adds 1 should be taken outside and shot.
When Norvig says talks of regular folks, he means people with 1/10th his IQ, which is still the top 1%. Norvig is so far out there on the IQ scale that I find it funny when some noob says he's found a bug!
Gargoyles represent the embarrassing side of the Central Intelligence Corporation. Instead of using laptops, they wear their computers on their bodies, broken up into separate modules that hang on the waist, on the back, on the headset. They serve as human surveillance devices, recording everything that happens around them. Nothing looks stupider; these getups are the modern-day equivalent of the slide-rule scabbard or the calculator pouch on the belt, marking the user as belonging to a class that is at once above and far below human society.
