title: Do I need transactional queues in Microservices?
body: <p>I'm learning about microservices and I understand that in my scenario I want microservices to communicate with each other using message queues, with persistence. That means if the instance crashes and the message is not consummed, it will be consumed when the instance bounces back (or maybe by another instance).</p>
  <p>Now, since these messages are critical, shouldn't they be transactional and participate in the <strong>micro</strong> database transaction? I see examples using Kafka or RabbitMQ but these queue implementations don't implement transactions. If they don't do it there's a clear chance some messages could be lost.</p>
  <p>Are transactions really needed for microservices at all? Or should I design my microservices in a resilient way so they can lose information, and recover from this scenario?</p>
  <p>Maybe my question doesn't make sense. Maybe I'm still thinking in the &quot;monolithic&quot; way where isolation, locking, and transactions are king.</p>