Skip to content

Minimum Viable Message Bus 🚌 #2

Description

@barlock

Overview

As an engineer connecting services, I want an always-on, tamper-resistant message bus to pass messages between services so that I can coordinate my services.

Reference

Questions

  • What patterns exist in other MQ, MB systems?
  • What steps should be put in place to prevent deadlocking?
    • Is it all on the client? Does the MB need to expose features to allow clients to prevent deadlocking?
    • Should a "time-lock" mechanism be put in place? See Atomic Crosschain Transactions. "Message slots" per topic for concurrency?

Assumptions

  • Optimize for keeping gas low

Acceptance

  • A smart contract to be used as a MB, it should:
    • accept a message and provide guarantees that once the calling process get's a successful return that the message is guaranteed (to some degree) to be durable.
    • Provide some way for services to request messages since a cursor (timestamp, vector, clock, hash chain, etc..)
    • Provide some scheme for additional metadata on the messages that could be read (optionally) by services and used for filtering. (topics, senders, etc.)
    • Emit events allowing services to process in real time
    • Allow for deadlock prevention (See questions)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions