# The Particular Service Platform Messaging is a great way to build loosely coupled, scalable, and reliable systems. It has its challenges, however; the most common difficulty is seeing what's happening in a system. This is one of the problems solved by the Particular Service Platform. The Platform's goal is to provide a set of tools that make it easier to build and maintain messaging systems. The tools are tailored to the common needs of messaging systems and 'just work' out of the box. They enable developers to focus on more important challenges, such as gaining a better understanding of their business domains. The Particular Service Platform consists of [NServiceBus](/nservicebus/index.md), [ServiceControl](/servicecontrol/index.md), and [ServicePulse](/servicepulse/index.md). ![Particular Service Platform architecture](architecture-overview.png 'width=800') The details of each component are discussed below. A Particular Service Platform-based system consists of several NServiceBus [endpoints](/nservicebus/endpoints/index.md). Endpoints are logical entities that perform business operations. They communicate with each other using messages (via queues) and forward messages to ServiceControl for auditing. ServiceControl stores this audit trail and provides integration points for ServicePulse. ServicePulse provides monitoring and recoverability for production systems, as well as debugging information and visualization of how the system works. ## [NServiceBus](/nservicebus/index.md) - where it all begins NServiceBus is the heart of a distributed system and the Particular Service Platform. It helps create systems that are scalable, reliable, and flexible. Adding NServiceBus to a project can be done via the .NET CLI: ```ps dotnet add package NServiceBus ``` At its core, NServiceBus works by routing _messages_ between _endpoints_. [Messages](/nservicebus/concepts/glossary.md#message) are plain C# classes that contain meaningful data for the business process being modeled. ```csharp public class ProcessOrder { public int OrderId { get; set; } } ``` [Endpoints](/nservicebus/concepts/glossary.md#endpoint) are logical entities that send and/or receive messages. ```csharp // Sending endpoint await endpoint.Send(new ProcessOrder { OrderId = 15 }); // Receiving endpoint public class ProcessOrderHandler : IHandleMessages { public async Task Handle(ProcessOrder message, IMessageHandlerContext context) { // Do something with ProcessOrder message } } ``` Endpoints can be running in different processes, on different machines, even at different times. NServiceBus ensures that each message reaches its intended destination and is processed. NServiceBus accomplishes this by providing an abstraction over [existing queuing technologies](/transports/index.md). While it's possible to work directly with queuing systems, NServiceBus provides extra features to make applications more reliable and scalable. ## Reliable NServiceBus offers different ways of ensuring information is not lost due to system failures. ### Transaction Support NServiceBus provides native transaction support (for underlying queuing technologies that have a native transactions feature), as well as its own transaction guarantees through the implementation of the [Outbox pattern](/nservicebus/outbox/index.md). ### Recoverability NServiceBus has [built-in recoverability](/nservicebus/recoverability/index.md) that can automatically adapt to common failures in a system. For intermittent failures, such as network outages, messages can be retried at regular intervals. For more serious errors, messages are set aside in a separate error queue so that they [can be investigated at a later time](/servicepulse/intro-failed-messages.md) without impacting the overall performance of the system. Watch this video for a better picture of how failures can lead to lost data, and how using NServiceBus keeps data safe.
> [!NOTE] > To see how NServiceBus prevents loss of data, adds failure recovery, and makes systems easier to extend, try the [NServiceBus Quick Start](/tutorials/quickstart/index.md). ## Scalable NServiceBus is designed to handle a large number of messages. Endpoints are configured for high performance by default, handling multiple messages in parallel. Depending on the workload, the number of messages handled concurrently can be [increased to improve message throughput](/nservicebus/operations/tuning.md). In high-volume scenarios, where more messages are produced than a single physical endpoint can handle, the logical endpoint can be [scaled out across multiple physical instances](/nservicebus/scaling.md) running on different machines, thus sharing the load. Each endpoint tracks [key performance metrics](/monitoring/metrics/definitions.md) that can be [exposed by OpenTelemetry](/nservicebus/operations/opentelemetry.md) and/or [collected into a central dashboard](/monitoring/metrics/in-servicepulse.md). [The monitoring demo](/tutorials/monitoring-demo/index.md) demonstrates how to find performance bottlenecks and identify endpoints that are ready to scale out. ## Simple and testable NServiceBus is designed with simplicity in mind. Message handlers don't need additional code to manage logging, exception handling, serialization, transactions, or the specifics of a queueing technology. This allows message handler code to focus on business logic. Long-running business workflows can be modeled in NServiceBus using [sagas](/nservicebus/sagas/index.md). A saga is a C# class that handles a number of different messages over time, persisting its state between each step in the workflow. NServiceBus makes sure that each saga instance only processes a single message at a time, keeping its internal state consistent. The [NServiceBus saga tutorials](/tutorials/nservicebus-sagas/index.md) provide more details. Message handlers and sagas can be [tested in isolation](/nservicebus/testing/index.md). Simulating an incoming message is as simple as creating a new C# message object and passing it to the appropriate handler or saga. The framework includes a suite of testing tools that capture the behavior of message handlers and sagas under test, allowing assertions to be made. ## Flexible NServiceBus endpoints can be hosted anywhere code can be executed, such as in a Windows Service, a Docker container, or in the cloud with Azure or AWS. Endpoints can run on [a variety of platforms](/nservicebus/upgrades/supported-platforms.md). NServiceBus works with many different technology stacks, offering choices for [transport](/transports/index.md) and [persistence](/persistence/index.md). Out of the box, defaults are provided for [serialization](/nservicebus/serialization/index.md), [dependency injection](/nservicebus/dependency-injection/index.md), and [logging](/nservicebus/logging/index.md). These defaults can be overridden if a specific technology is desired. The NServiceBus message processing and dispatching pipeline is modular and extensible. The message processing pipeline can be manipulated with [behaviors](/nservicebus/pipeline/manipulate-with-behaviors.md), which are similar to ASP.NET middleware. NServiceBus extensions can be packaged up as [features](/nservicebus/pipeline/features.md), which can add behaviors to the pipeline and create tasks that get run when an endpoint starts and stops. Many of the existing capabilities of NServiceBus are implemented as behaviors and features. ## NServiceBus as part of the Particular Service Platform NServiceBus is designed to work with the rest of the Particular Service Platform. All messages are instrumented with additional [headers](/nservicebus/messaging/headers.md) detailing key information about the message and how it was processed. As each message is processed, it can be forwarded to an [audit queue](/nservicebus/operations/auditing.md), where it is picked up by [ServiceControl](/servicecontrol/index.md). When a message fails to be processed, even after a number of retry strategies have been attempted, NServiceBus will forward the message to an [error queue](/nservicebus/recoverability/configure-error-handling.md) for manual investigation. Messages sent to the error queue are instrumented with headers containing details about the failure, including a full exception stack trace. ServiceControl picks up messages from the error queue and makes them available for viewing in [ServicePulse](/servicepulse/index.md). Once the root cause of the failure has been found and corrected, all messages caused by the same problem can be retried as a single operation. Additionally, each endpoint can send [heartbeat](/monitoring/heartbeats/index.md), [health check](/monitoring/custom-checks/index.md), and [performance metrics](/monitoring/metrics/index.md) through the platform for visualization in ServicePulse, making it easy to see which endpoints are offline, which are ready to scale out, and which require manual intervention. Message visualizations available in [ServicePulse](/servicepulse/message-details.md#messages-with-audited-conversation-data) make it easy to understand message flows and timing of a running NServiceBus system. ## See it in action * **[Real-time monitoring demo](https://particular.net/real-time-monitoring)** - Experience the Service Platform in action. * **[Quickstart tutorial](/tutorials/quickstart/index.md)** - Get a tour through an NServiceBus solution covering all the elements of one-way messaging, publish-subscribe, and automatic recovery from exceptions. * **[(Video) Live coding an NServiceBus system](https://particular.net/webinars/live-coding-your-first-nservicebus-system)** - For those who prefer to sit back and watch an experienced developer build a messaging system with NServiceBus. * **[Platform Sample package](/platform/platform-sample-package.md)** - Demonstrate the Service Platform from within any .NET Project, without the need to install anything. ## [ServiceControl](/servicecontrol/index.md) - data collection ServiceControl is the backend for ServicePulse. It is a background process that collects useful information about an NServiceBus system. This includes: - Messages that cannot be processed, along with their exceptions - [Every message](/nservicebus/operations/auditing.md) flowing through the system - [Saga](/nservicebus/sagas/saga-audit.md) state changes - Endpoint [heartbeats](/monitoring/heartbeats/index.md) - [Detailed performance metrics](/monitoring/metrics/index.md) ServiceControl can also be used to perform [custom checks](/monitoring/custom-checks/index.md). All this information is exposed to [ServicePulse](/servicepulse/index.md) via an HTTP API. ## [ServicePulse](/servicepulse/index.md) - debug, retry, monitor and visualize ServicePulse is a web application designed to provide both administrators and developers with powerful tools for monitoring and managing systems. It offers a clear, near real-time, high-level overview of system functionality, along with common failure recovery operations such as retrying failed messages. Additionally, it provides a rich, graphical view of [detailed performance metrics](/monitoring/metrics/in-servicepulse.md), including insights into logical endpoints, physical instances, and individual message types. For administrators, ServicePulse simplifies system oversight and is essential for generating [usage reports](/servicepulse/usage.md) to determine licensing requirements. For developers, it offers advanced debugging capabilities; including visualizations of message flows, saga state changes, and other system behaviors. Tools like message [flow diagrams](/servicepulse/flow-diagram.md) and [sequence diagrams](/servicepulse/sequence-diagram.md) make it easy to detect anomalies and incorrect behavior. Developers can also access detailed information, such as message headers and metadata, when viewing individual messages. ## Working with the platform ServiceControl and ServicePulse are server applications. They should be deployed in each environment, for example: test, QA, and production. When investigating problems or developing [custom checks](/monitoring/custom-checks/index.md), it can be useful to have the Platform installed on a development machine. ## Additional resources Two [showcases](/samples/showcase/loan-broker-showcase/index.md), one targeting Azure and the other targeting AWS, demonstrate how to integrate the Particular Service Platform.