Message brokers are a system that eases the communication between different applications, systems, and services to exchange information by translating them between formal messaging protocols. With these brokers, the interdependent services can interact even if they are in different languages or are implemented on different platforms. These messages can be validated, stored, routed, or delivered to the designated receiver.
Message brokers are the intermediate medium between various applications where the senders are not aware of the receivers. The message is sent without any knowledge about the receivers or their locations. With this, it decouples the processes and services within the system.
Some of the common examples of message brokers are NATS, Apache Kafka, RabbitMQ, ActiveMQ, etc.
Models
There are two models of message brokers.
1. Point-to-Point Messaging
Message queues implement a point-to-point messaging pattern where there is a one-to-one relationship between the one who sends and the one who receives.
2. Publish-Subscribe Messaging
There is a producer of each message topic and consumers subscribe to topics to receive the message. This pattern is called the Publisher-Subscriber pattern — pub/sub.
Message Brokers Vs. Event Streaming
| S.N. | Factors | Message Brokers | Event Streaming |
|---|---|---|---|
| 1. | Messaging Patterns | Two - Message Queues and Publisher-Subscriber distribution patterns | Only Publisher-Subscriber distribution patterns |
| 2. | Scalability | Less Scalable | More Scalable |
| 3. | Message Delivery | Guaranteed | Not Guaranteed |
| 4. | Fault Tolerance | More suited with message queues and pub\sub | Message Resending procedure |
| 5. | Message Routing | Better than event streaming | Limited |
| 6. | Queuing Capabilitites | Better than event streaming | Limited |
Message Broker Vs. Enterprise Service Bus (ESB)
| S.N. | Message Broker | Enterprise Service Bus (ESB) |
|---|---|---|
| 1. | Comparatively less complex | More complex |
| 2. | Integration is easy. | Integration is challenging. |
| 3. | Maintenance is cost-effective. | Maintenance is expensive. |
| 4. | Updating is easy for inter-service communication. | Updating can be mind-wrecking. |
| 5. | Troubleshoot is easy. | Difficult to troubleshoot when problems occur in production environments. |
| 6. | More suitable for the microservices architectures. | ESB is falling out of favor. |
pragyaasapkota
/
System-Design-Concepts
Though the concepts of system design might be tricky, let's see them individually to their core concepts and have a better understanding.
System Design
Systems design is the process of defining elements of a system like modules, architecture, components and their interfaces and data for a system based on the specified requirements.
This is a index for the concepts of system.
If you wish to open these in a new tab, Press CTRL+click
| S.N. | Table of Content |
|---|---|
| 1. | Caching |
| 2. | Network Protocols |
| 3. | Storage: The Underrated Topic |
| 4. | Latency and Throughput |
| 5. | System Availability |
| 6. | Leader Election |
| 7. | Proxies |
| 8. | Load Balancing |
| 9. | Endpoint Protection |
| 10. | HTTPS: Is it better than HTTP? |
| 11. | Polling and Streaming |
| 12. | Long Polling |
| 13. | Hashing |
| 14. | CAP Theorem |
| 15. | PACELC Theorem |
| 16. | Messaging and Pub-Sub |
| 17. | Database |
| 18. | Logging, Monitoring, and Alerting |
| 19. | Distributed System |
| 20. | Scaling |
| 21. | Event Driven Architecture (EDA) |
| 22. | CQRS |
| 23. | Message Queue |
| 24. | Architectural Patterns |
| 25. |
I hope this article was helpful to you.
Please don’t forget to follow me!!!
Any kind of feedback or comment is welcome!!!
Thank you for your time and support!!!!
Keep Reading!! Keep Learning!!!
Top comments (0)