2 Pulsar Concepts and Architecture

Now that you have been introduced to the Pulsar messaging platform and how it compares to other messaging systems, I will drill down into the low-level architectural details of the platform and cover some of the unique terminology used by the platform. If you are unfamiliar with messaging systems and distributed systems, then it might be difficult to wrap your head around some of the Pulsar's concepts and terminology. Therefore, I will introduce them in a progressive fashion using a more concrete example.

2.1      Pulsar’s Logical Architecture

Our food delivery platform will have multiple services using the Pulsar messaging platform to send and receive information between one another. The ones we are concerned about for our mobile application include the driver location service which publishes the driver’s location events that we use to update the customer on the status of their order while it is in-route. Since we are anticipating a large volume of customers during peak times, there could potentially be 10s of thousands of subscriptions to our driver location topic, one for each outstanding food order.

2.1.1      Tenants, Namespaces, and Topics

2.1.2      Addressing Topics in Pulsar

2.1.3      Producers, Consumers, and Subscriptions

2.1.4      Subscription Types

2.2      Pulsar’s Physical Architecture

2.2.1      Pulsar’s Layered Architecture

2.2.2      Stateless Serving Layer

2.2.3      Stream Storage Layer

2.2.4      Metadata Storage

2.3      Message Retention and Expiration

2.3.1      Data Retention

2.3.2      Backlog Quotas

2.3.3      Message Expiration

2.3.4      Message Backlog vs. Message Expiration

2.4      Tiered Storage

2.5      Summary