8 ms·

Whoa! This is a game changer! I was looking into both Kafka and Google Pub/Sub for a event-oriented system my team was designing. Google Pub/Sub looked very pro

Whoa! This is a game changer! I was looking into both Kafka and Google Pub/Sub for a event-oriented system my team was designing. Google Pub/Sub looked very promising, but no guarantee of ordering was a deal breaker for us. I’ll consider this more strongly for the next system we build.

edoceo 6y ago
What did you pick? I'm interested in non-G solutions.
- wngr 6y ago
  Probably Kafka according to his comment.
doh 6y ago
We used Pub/Sub very extensively (50B messages a day) but moved to Pulsar [0]. It performs equally well and has some nice features. And also no vendor lock-in. [0] https://kesque.com/billions-of-events-a-day-without-breaking-the-bank-how-pex-avoided-cloud-provider-lock-in-and-saved-over-50-with-kesque-managed-cluster-plan/ https://kesque.com/billions-of-events-a-day-without-breaking...
- seg_lol 6y ago
  Given cloud vendors low respect for their customers, the proper stance is to own your own infrastructure.
  - snypox 6y ago
    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...
    - seg_lol 6y ago
      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.
      - snypox 6y ago
        I understand. I’m just saying that in my my professional experience, nothing good came out of religously avoiding lock-in but the opposite.
        outsomnia 6y ago
        With respect, clearly you cannot extrapolate that particular experience very far. Otherwise, eg, FOSS is "nothing good".
        snypox 6y ago
        I'm not talking about "that" particular experience, but in general.
    - deleted 6y ago
      [deleted]
    - roland35 6y ago
      I agree with this, the best parts of the cloud is abstracting away a lot of the basic maintenance of these applications. There is lock in to some platform no matter what you do, but hopefully you can design your application so that if you do need to rearchitect you can do it in phases.
- atombender 6y ago
  Pulsar seems operationally quite complex, as it has a dependency on both BookKeeper and ZooKeeper (which BK also needs). ZooKeeper is particularly notorious for being difficult. What's your experience been like?
  - doh 6y ago
    It definitely is on the more complex side of management. That's why we partnered with Kafkaesque to do the maintenance for us. We were fine handling it ourselves but decided to outsource it as it's less critical for us than many other internal tasks. They have an open ticket [0] to dilute zookeeper's dependance, but as far as I know it's still pending. [0] https://github.com/apache/pulsar/issues/572 https://github.com/apache/pulsar/issues/572
staticassertion 6y ago
What's a use case where strict ordering is critically important?
- trimbo 6y ago
  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.
  - tyrust 6y ago
    Does adding timestamps not handle this case?
    - jedmeyers 6y ago
      If events are generated by different processes you cannot really guarantee that time is exactly the same for them, unless you do something fancy to ensure that.
      - zaphirplane 6y ago
        Interesting. The ordering here is when the event was generated or when the event entered the queue ? I think the later and so I think the examples here don’t apply without something on top and a trade off
        jedmeyers 6y ago
        The queue entrypoint is not always the same process either, especially in a system like Pub/Sub.
    - jurre 6y ago
      Now you need to queue up events for some time, reorder them using the timestamp, and then process them. It’s possible, but has overhead in both performance and custom code you’ll have to maintain. If there is no guarantee of order, two separate systems consuming those same events also might get different results, depending on the implementation, that can be problematic
himoacs 6y ago
If you are still looking, I would recommend Solace PubSub+: https://solace.com/products/event-broker/software/ https://solace.com/products/event-broker/software/ Supports zero message loss, no headaches around topic partitions, in-order messaging, support for open apis/protocols, in-memory AND persistent quality of service, support for event mesh etc

edoceo 6y ago

What did you pick? I'm interested in non-G solutions.

wngr 6y ago
Probably Kafka according to his comment.

doh 6y ago

We used Pub/Sub very extensively (50B messages a day) but moved to Pulsar [0]. It performs equally well and has some nice features. And also no vendor lock-in. [0] https://kesque.com/billions-of-events-a-day-without-breaking-the-bank-how-pex-avoided-cloud-provider-lock-in-and-saved-over-50-with-kesque-managed-cluster-plan/ https://kesque.com/billions-of-events-a-day-without-breaking...

seg_lol 6y ago
Given cloud vendors low respect for their customers, the proper stance is to own your own infrastructure.
- snypox 6y ago
  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...
  - seg_lol 6y ago
    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.
    - snypox 6y ago
      I understand. I’m just saying that in my my professional experience, nothing good came out of religously avoiding lock-in but the opposite.
      - outsomnia 6y ago
        With respect, clearly you cannot extrapolate that particular experience very far. Otherwise, eg, FOSS is "nothing good".
        snypox 6y ago
        I'm not talking about "that" particular experience, but in general.
  - deleted 6y ago
    [deleted]
  - roland35 6y ago
    I agree with this, the best parts of the cloud is abstracting away a lot of the basic maintenance of these applications. There is lock in to some platform no matter what you do, but hopefully you can design your application so that if you do need to rearchitect you can do it in phases.
atombender 6y ago
Pulsar seems operationally quite complex, as it has a dependency on both BookKeeper and ZooKeeper (which BK also needs). ZooKeeper is particularly notorious for being difficult. What's your experience been like?
- doh 6y ago
  It definitely is on the more complex side of management. That's why we partnered with Kafkaesque to do the maintenance for us. We were fine handling it ourselves but decided to outsource it as it's less critical for us than many other internal tasks. They have an open ticket [0] to dilute zookeeper's dependance, but as far as I know it's still pending. [0] https://github.com/apache/pulsar/issues/572 https://github.com/apache/pulsar/issues/572

staticassertion 6y ago

What's a use case where strict ordering is critically important?

trimbo 6y ago
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.
- tyrust 6y ago
  Does adding timestamps not handle this case?
  - jedmeyers 6y ago
    If events are generated by different processes you cannot really guarantee that time is exactly the same for them, unless you do something fancy to ensure that.
    - zaphirplane 6y ago
      Interesting. The ordering here is when the event was generated or when the event entered the queue ? I think the later and so I think the examples here don’t apply without something on top and a trade off
      - jedmeyers 6y ago
        The queue entrypoint is not always the same process either, especially in a system like Pub/Sub.
  - jurre 6y ago
    Now you need to queue up events for some time, reorder them using the timestamp, and then process them. It’s possible, but has overhead in both performance and custom code you’ll have to maintain. If there is no guarantee of order, two separate systems consuming those same events also might get different results, depending on the implementation, that can be problematic

himoacs 6y ago

If you are still looking, I would recommend Solace PubSub+: https://solace.com/products/event-broker/software/ https://solace.com/products/event-broker/software/ Supports zero message loss, no headaches around topic partitions, in-order messaging, support for open apis/protocols, in-memory AND persistent quality of service, support for event mesh etc