What is NServiceBus and what are its top alternatives?
Top Alternatives to NServiceBus
- Azure Service Bus
It is a cloud messaging system for connecting apps and devices across public and private clouds. You can depend on it when you need highly-reliable cloud messaging service between applications and services, even when one or more is offline. ...
- RabbitMQ
RabbitMQ gives your applications a common platform to send and receive messages, and your messages a safe place to live until received. ...
- Kafka
Kafka is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system, but with a unique design. ...
- Akka
Akka is a toolkit and runtime for building highly concurrent, distributed, and resilient message-driven applications on the JVM. ...
- MassTransit
It is free software/open-source .NET-based Enterprise Service Bus software that helps Microsoft developers route messages over MSMQ, RabbitMQ, TIBCO and ActiveMQ service busses, with native support for MSMQ and RabbitMQ. ...
- MSMQ
This technology enables applications running at different times to communicate across heterogeneous networks and systems that may be temporarily offline. Applications send messages to queues and read messages from queues. ...
- Hangfire
It is an open-source framework that helps you to create, process and manage your background jobs, i.e. operations you don't want to put in your request processing pipeline. It supports all kind of background tasks – short-running and long-running, CPU intensive and I/O intensive, one shot and recurrent. ...
- Apache Camel
An open source Java framework that focuses on making integration easier and more accessible to developers. ...
NServiceBus alternatives & related posts
- Easy Integration with .Net4
- Cloud Native2
- Use while high messaging need1
- Observability of messages in the queue is lacking1
related Azure Service Bus posts
Want to get the differences in features and enhancement, pros and cons, and also how to Migrate from IBM MQ to Azure Service Bus.
- It's fast and it works with good metrics/monitoring232
- Ease of configuration79
- I like the admin interface58
- Easy to set-up and start with50
- Durable20
- Standard protocols18
- Intuitive work through python18
- Written primarily in Erlang10
- Simply superb8
- Completeness of messaging patterns6
- Scales to 1 million messages per second3
- Reliable3
- Better than most traditional queue based message broker2
- Distributed2
- Supports MQTT2
- Supports AMQP2
- Inubit Integration1
- Open-source1
- Delayed messages1
- Runs on Open Telecom Platform1
- High performance1
- Reliability1
- Clusterable1
- Clear documentation with different scripting language1
- Great ui1
- Better routing system1
- Too complicated cluster/HA config and management9
- Needs Erlang runtime. Need ops good with Erlang runtime6
- Configuration must be done first, not by your code5
- Slow4
related RabbitMQ posts
As Sentry runs throughout the day, there are about 50 different offline tasks that we execute—anything from “process this event, pretty please” to “send all of these cool people some emails.” There are some that we execute once a day and some that execute thousands per second.
Managing this variety requires a reliably high-throughput message-passing technology. We use Celery's RabbitMQ implementation, and we stumbled upon a great feature called Federation that allows us to partition our task queue across any number of RabbitMQ servers and gives us the confidence that, if any single server gets backlogged, others will pitch in and distribute some of the backlogged tasks to their consumers.
#MessageQueue
Hi, I am building an enhanced web-conferencing app that will have a voice/video call, live chats, live notifications, live discussions, screen sharing, etc features. Ref: Zoom.
I need advise finalizing the tech stack for this app. I am considering below tech stack:
- Frontend: React
- Backend: Node.js
- Database: MongoDB
- IAAS: #AWS
- Containers & Orchestration: Docker / Kubernetes
- DevOps: GitLab, Terraform
- Brokers: Redis / RabbitMQ
I need advice at the platform level as to what could be considered to support concurrent video streaming seamlessly.
Also, please suggest what could be a better tech stack for my app?
#SAAS #VideoConferencing #WebAndVideoConferencing #zoom #stack
Kafka
- High-throughput126
- Distributed119
- Scalable90
- High-Performance85
- Durable65
- Publish-Subscribe37
- Simple-to-use19
- Open source18
- Written in Scala and java. Runs on JVM11
- Message broker + Streaming system8
- Robust4
- Avro schema integration4
- KSQL4
- Suport Multiple clients3
- Partioned, replayable log2
- Extremely good parallelism constructs1
- Fun1
- Flexible1
- Simple publisher / multi-subscriber model1
- Non-Java clients are second-class citizens31
- Needs Zookeeper28
- Operational difficulties8
- Terrible Packaging3
related Kafka posts










The algorithms and data infrastructure at Stitch Fix is housed in #AWS. Data acquisition is split between events flowing through Kafka, and periodic snapshots of PostgreSQL DBs. We store data in an Amazon S3 based data warehouse. Apache Spark on Yarn is our tool of choice for data movement and #ETL. Because our storage layer (s3) is decoupled from our processing layer, we are able to scale our compute environment very elastically. We have several semi-permanent, autoscaling Yarn clusters running to serve our data processing needs. While the bulk of our compute infrastructure is dedicated to algorithmic processing, we also implemented Presto for adhoc queries and dashboards.
Beyond data movement and ETL, most #ML centric jobs (e.g. model training and execution) run in a similarly elastic environment as containers running Python and R code on Amazon EC2 Container Service clusters. The execution of batch jobs on top of ECS is managed by Flotilla, a service we built in house and open sourced (see https://github.com/stitchfix/flotilla-os).
At Stitch Fix, algorithmic integrations are pervasive across the business. We have dozens of data products actively integrated systems. That requires serving layer that is robust, agile, flexible, and allows for self-service. Models produced on Flotilla are packaged for deployment in production using Khan, another framework we've developed internally. Khan provides our data scientists the ability to quickly productionize those models they've developed with open source frameworks in Python 3 (e.g. PyTorch, sklearn), by automatically packaging them as Docker containers and deploying to Amazon ECS. This provides our data scientist a one-click method of getting from their algorithms to production. We then integrate those deployments into a service mesh, which allows us to A/B test various implementations in our product.
For more info:
- Our Algorithms Tour: https://algorithms-tour.stitchfix.com/
- Our blog: https://multithreaded.stitchfix.com/blog/
- Careers: https://multithreaded.stitchfix.com/careers/
#DataScience #DataStack #Data










As we've evolved or added additional infrastructure to our stack, we've biased towards managed services. Most new backing stores are Amazon RDS instances now. We do use self-managed PostgreSQL with TimescaleDB for time-series data—this is made HA with the use of Patroni and Consul.
We also use managed Amazon ElastiCache instances instead of spinning up Amazon EC2 instances to run Redis workloads, as well as shifting to Amazon Kinesis instead of Kafka.
- Great concurrency model32
- Fast17
- Actor Library12
- Open source10
- Resilient7
- Message driven5
- Scalable5
- Mixing futures with Akka tell is difficult3
- Closing of futures2
- No type safety2
- Very difficult to refactor1
- Typed actors still not stable1
related Akka posts
To solve the problem of scheduling and executing arbitrary tasks in its distributed infrastructure, PagerDuty created an open-source tool called Scheduler. Scheduler is written in Scala and uses Cassandra for task persistence. It also adds Apache Kafka to handle task queuing and partitioning, with Akka to structure the library’s concurrency.
The service’s logic schedules a task by passing it to the Scheduler’s Scala API, which serializes the task metadata and enqueues it into Kafka. Scheduler then consumes the tasks, and posts them to Cassandra to prevent data loss.
I decided to use Akka instead of Kafka streams because I have personal relationships at @Lightbend.
related MassTransit posts
- Easy to learn2
- Cloud not needed1
- Windows dependency1
related MSMQ posts
- Integrated UI dashboard7
- Simple5
- Robust3
- In Memory2
- Simole0
related Hangfire posts
- Based on Enterprise Integration Patterns5
- Has over 250 components4
- Free (open source)4
- Highly configurable4
- Open Source3
- Has great community2