LogoLogo
CloudDiscordGitHub
  • 👉Getting Started
    • Introduction
    • Quick start
    • Learn by example
    • Case studies
    • How to contribute?
  • ⭐Memphis Broker
    • Architecture
    • Key concepts
      • Message broker
      • Station
      • Producer API
      • Consumer API
      • Consumer Group
      • Storage and Redundancy
      • Security/Authentication
      • Scaling
      • Ordering
      • Dead-letter Station (DLS)
      • Delayed messages
      • Data exchange
      • Idempotency (Duplicate processing)
      • Failover Scenarios
      • Troubleshooting process
      • Connectors
    • Best practices
      • Producer optimization
      • Compression
    • Memphis configuration
    • Comparisons
      • NATS Jetstream vs Memphis
      • RabbitMQ vs Memphis
      • AWS SQS vs Memphis
      • Apache Kafka vs Memphis
      • Apache Pulsar vs Memphis
      • ZeroMQ vs Memphis
      • Apache NiFi vs Memphis
    • Privacy Policy
  • ⭐Memphis Schemaverse
    • Overview
    • Getting started
      • Management
      • Produce/Consume
        • Protobuf
        • JSON Schema
        • GraphQL
        • Avro
    • Comparison
    • KB
  • 📦Open-Source Installation
    • Kubernetes
      • 1 - Installation
      • 2 - Access
      • 3 - Upgrade
      • Terraform
        • Deploy on AWS
        • Deploy on GCP
        • Deploy on DigitalOcean
      • Guides
        • Deploy/Upgrade Memphis utilizing predefined secrets
        • Monitoring/Alerts Recommendations
        • Production Best Practices
        • NGINX Ingress Controller and Cloud-Agnostic Memphis Deployments
        • Migrate Memphis storage between storageClass's
        • Expanding Memphis Disk Storage
        • Scale-out Memphis cluster
        • TLS - Deploy Memphis with TLS Connection to Metadata Frontend
        • TLS - Memphis TLS websocket configuration
        • TLS - Securing Memphis Client with TLS
        • Installing Memphis with an External Metadata Database
    • Docker
      • 1 - Installation
      • 2 - Access
      • 3 - Upgrade
    • Open-source Support
  • Client Libraries
    • REST (Webhook)
    • Node.js / TypeScript / NestJS
    • Go
    • Python
    • Kotlin (Community)
    • .NET
    • Java
    • Rust (Community)
    • NATS
    • Scala
  • 🔌Integrations Center
    • Index
    • Processing
      • Zapier
    • Change data Capture (CDC)
      • Debezium
    • Monitoring
      • Datadog
      • Grafana
    • Notifications
      • Slack
    • Storage tiering
      • S3-Compatible Object Storage
    • Source code
      • GitHub
    • Other platforms
      • Argo
  • 🗒️Release notes
    • KB
    • Releases
      • v1.4.3 - latest/stable
      • v1.4.2
      • v1.4.1
      • v1.4.0
      • v1.3.1
      • v1.3.0
      • v1.2.0
      • v1.1.1
      • v1.1.0
      • v1.0.3
      • v1.0.2
      • v1.0.1
      • V1.0.0 - GA
      • v0.4.5 - beta
      • v0.4.4 - beta
      • v0.4.3 - beta
      • v0.4.2 - beta
      • v0.4.1 - beta
      • v0.4.0 - beta
      • v0.3.6 - beta
      • v0.3.5 - beta
      • v0.3.0 - beta
      • v0.2.2 - beta
      • v0.2.1 - beta
      • v0.2.0 - beta
      • v0.1.0 - beta
Powered by GitBook
LogoLogo

Legal

  • Terms of Service
  • Privacy Policy

All rights reserved to Memphis.dev 2023

On this page
  • What is a message broker?
  • Purpose
  • Differences between Broker, Pub/Sub, Queue

Was this helpful?

  1. Memphis Broker
  2. Key concepts

Message broker

What is a message broker?

A message broker is an intermediary software component or system that facilitates communication and data exchange between various applications or components in a distributed computing environment. It plays a crucial role in enabling asynchronous communication, decoupling the sender and receiver of messages, and ensuring reliable and efficient data transfer between different parts of a system.

Purpose

  1. Message Routing: Message brokers receive messages from producers (senders) and route them to the appropriate consumers (receivers) based on defined criteria, such as message content, destination, or topic. This enables the decoupling of components, as producers and consumers don't need to know each other's details.

  2. Message Transformation: Message brokers can perform data format transformations or protocol translations to ensure that messages sent by producers are compatible with the expectations of consumers. This allows systems with different data formats or protocols to communicate seamlessly.

  3. Message Queues: Many message brokers use message queues to store and manage messages until they are consumed. This provides a buffer that can help handle spikes in message traffic and ensures that messages are not lost even if consumers are temporarily unavailable.

  4. Publish-Subscribe Model: Message brokers often support the publish-subscribe (pub-sub) pattern, where producers publish messages to topics, and multiple consumers subscribe to those topics to receive relevant messages. This enables broadcasting messages to multiple consumers without them knowing about each other.

  5. Message Persistence: Some message brokers offer message persistence, which means that messages are stored on disk to ensure data durability even if the broker or consumers experience failures. This is essential for critical and reliable message delivery.

  6. Load Balancing: Message brokers can distribute messages to multiple consumers to balance the load and ensure that no single consumer is overwhelmed with too many messages. This is especially useful in scenarios with high message volumes.

  7. Scalability and Fault Tolerance: Message brokers are often designed to be highly scalable and fault-tolerant, allowing them to handle a growing number of messages and recover from failures without data loss.

Message brokers are used in a wide range of applications, including microservices architectures, IoT (Internet of Things) systems, financial trading platforms, and more, to enable efficient and reliable communication between different components or services.

Differences between Broker, Pub/Sub, Queue

"Broker," "Publish-Subscribe (Pub/Sub)," and "Queue" are terms often used in the context of messaging systems, and they represent different patterns or approaches for message communication and distribution. Here are the key differences between these concepts:

  1. Broker:

    • A "broker" is a more general term that refers to any system or component that mediates and manages message communication between producers (senders) and consumers (receivers).

    • Brokers can implement various messaging patterns, including both Pub/Sub and Queue patterns, and may offer additional features such as message transformation, routing, and persistence.

    • Memphis.dev is a message broker.

  2. Publish-Subscribe (Pub/Sub):

    • Publish-Subscribe, often abbreviated as Pub/Sub, is a specific messaging pattern.

    • In the Pub/Sub pattern, producers (publishers) send messages to named topics or channels, and multiple consumers (subscribers) can subscribe to those topics to receive messages.

    • Messages published to a topic are broadcast to all interested subscribers. Subscribers don't need to know about the existence of other subscribers.

    • Pub/Sub is well-suited for scenarios where messages need to be broadcast to multiple consumers or where consumers are interested in specific types of messages.

  3. Queue:

    • A message queue is another specific messaging pattern, often used for point-to-point communication.

    • In the Queue pattern, producers send messages to a specific queue, and only one consumer (or one of several competing consumers) receives and processes each message.

    • Messages in a queue are typically processed in the order they were received, and each message is consumed by a single consumer. This ensures that messages are processed sequentially and not duplicated.

    • Message queues are useful when you need to ensure that each message is processed by a single consumer, such as in task processing or load-balancing scenarios.

Last updated 1 year ago

Was this helpful?

⭐
Page cover image