AWS SQS vs Memphis.dev
This article describes the differences between AWS SQS and Memphis.dev.
Join the DZone community and get the full member experience.Join For Free
What is AWS SQS?
Amazon Simple Queue Service (Amazon SQS) offers a secure, durable, and available hosted queue that lets you integrate and decouple distributed software systems and components. Amazon SQS offers common constructs such as dead-letter queues and cost allocation tags. It provides a generic web services API that you can access using any programming language that the AWS SDK supports.
What is Memphis.dev?
Memphis is a next-generation messaging queue.
A simple, robust, and durable cloud-native message broker wrapped with an entire ecosystem that enables fast and reliable development of next-generation event-driven use cases.
Memphis.dev enables building next-generation applications that require large volumes of streamed and enriched data, modern protocols, zero ops, rapid development, extreme cost reduction, and a significantly lower amount of dev time for data-oriented developers and data engineers.
SQS uses a distinct, bounded data flow. Messages are created and sent by the producer and received by the consumer.
Memphis uses an unbounded data flow, with the key-value pairs continuously streaming to the assigned station.
AWS SQS is best for transactional data, such as order formation, placement, and user requests.
Memphis works great for transactional and operational data like process operations, auditing and logging statistics, and system activity.
AWS SQS pushes messages to consumers. These messages are removed from the queue once they are processed and acknowledged.
Memphis is a log. It uses continuous messages, which stay in the station (queue) until the retention period expires.
AWS SQS doesn’t support multi-tenancy but through a lambda function, required to be coded and managed by the user that acts as a router.
Memphis supports multi-tenancy using namespaces which offers a complete separation from connections, producers, consumers, security, dedicated dashboard, including node selection.
Some level of observability can be received by using 3rd party apps like Cloudwatch/Datadog/New Relic. To understand the full path of a message, it is required to use AWS X-Ray and add some headers to each client. Notifications can be achieved by building a dedicated event queue with lambda triggers. Some alarms and triggers must be defined over 3rd party apps to enable lag identifications and latency in real time.
Memphis offers full Infra-to-cluster-to-data GUI-based observability, monitoring, real-time message tracing, and notifications embedded inside the management layer, including self-healing policies based on the defined events.
Published at DZone with permission of Yaniv Ben Hemo. See the original article here.
Opinions expressed by DZone contributors are their own.