Content pfp
Content
@
0 reply
0 recast
2 reactions

Varun Srinivasan pfp
Varun Srinivasan
@v
Anyone here worked on an eng team that processed more than 100M background jobs /day? Starting to run into issues with our setup. Looking for ideas on what people typically turn to at this scale.
28 replies
20 recasts
142 reactions

Alberto Ornaghi pfp
Alberto Ornaghi
@alor
Interesting challenge. it heavily depends on the kind of jobs you need to process. Do they have a shared state? Are they fire & forget? CPU or IO intensive? So many cases… Would love to follow the conversation on this topic.
1 reply
0 recast
2 reactions

Varun Srinivasan pfp
Varun Srinivasan
@v
shared state. think generating home feeds, updating reaction counts etc
3 replies
0 recast
4 reactions

William Saar pfp
William Saar
@saarw.eth
Sounds like a good problem for stream processing. Dump activity as events on a Kafka queue and a Flink job, or multiple jobs for unrelated app functionality, can be scaled out to do the processing ...Kafka was invented at LinkedIn to handle social app updates after all
1 reply
0 recast
2 reactions

William Saar pfp
William Saar
@saarw.eth
And yes, I've worked at King when we processed events for 100M DAU with Flink. If you're running in GCP, like Spotify, their Dataflow infra also offers similar functionality that works at that scale
0 reply
0 recast
1 reaction