21–30 of 114 posts
Earlier quoted context omitted.
What's a use case where strict ordering is critically important?
Consider processing two events without guaranteed ordering: - Create A - Delete A In one ordering, A is created and then deleted as expected, in the other, the delete fails but then A is created and remains.
Earlier quoted context omitted.
Given cloud vendors low respect for their customers, the proper stance is to own your own infrastructure.
The company I work for had the same stance 5 years ago. We regretted it a hundred times and now we stand the gaff. Nothing better than maintaining an EC2 based Cassandra cluster instead of simple using DynamoDB, huh...
Stances are not strategies, when we use another's API we form a bond but the the other is free to break it so we are automatically at a weaker position. We have acquiesced. But if we choose a strategically worse choice, we have not only acquiesced, but done self-harm.
Earlier quoted context omitted.
Given cloud vendors low respect for their customers, the proper stance is to own your own infrastructure.
The company I work for had the same stance 5 years ago. We regretted it a hundred times and now we stand the gaff. Nothing better than maintaining an EC2 based Cassandra cluster instead of simple using DynamoDB, huh...
Earlier quoted context omitted.
Consider processing two events without guaranteed ordering: - Create A - Delete A In one ordering, A is created and then deleted as expected, in the other, the delete fails but then A is created and remains.
Does adding timestamps not handle this case?
Earlier quoted context omitted.
The company I work for had the same stance 5 years ago. We regretted it a hundred times and now we stand the gaff. Nothing better than maintaining an EC2 based Cassandra cluster instead of simple using DynamoDB, huh...
I don't believe I advocated for the use of Cassandra. Owning vs being owned by, we are not arguing about the same things. Stances are not strategies, when we use another's API we form a bond but the the other is free to break it so we are automatically at a weaker position. We have acquiesced. But if we choose a strategically worse choice, we have not only acquiesced, but done self-harm.
I'm floored by this. Last I spoke with that team the response was a few (but not everyone) in leadership getting it and everyone else asking why we would care. How far to come. GCP just got substantially more interesting. Edit: by this I only mean to say well done to the Google team.
By the way, in addition to ordered messages, Pub/Sub has recently gotten a number of new features including message filtering, dead letter queues, and retry policy (some GA, some beta). You can find out more here: https://cloud.google.com/pubsub/docs/release-notes Disclaimer: I work on Pub/Sub
Earlier quoted context omitted.
What's a use case where strict ordering is critically important?
Consider processing two events without guaranteed ordering: - Create A - Delete A In one ordering, A is created and then deleted as expected, in the other, the delete fails but then A is created and remains.
- jobs can have ever increasing ids, workers record the last seen id in one place, and ignore jobs with ids less than last seen
- job results are returned for each job to a supervisor. if a job result doesn't match current expected state, resend job. jobs should be idempotent in case a job is sent multiple times
If the create job is expensive, the latter solution would be less ideal, though.
Earlier quoted context omitted.
Consider processing two events without guaranteed ordering: - Create A - Delete A In one ordering, A is created and then deleted as expected, in the other, the delete fails but then A is created and remains.
Does adding timestamps not handle this case?