Don't Panic — Apache Pulsar Fundamentals

Apache Pulsar is a messaging and streaming platform that lets one application put a message somewhere reliable while other applications collect it on their own schedules. It is not a magic mailbox. It is a deliberately large arrangement of brokers, storage nodes, policies, and cursors, because a small arrangement tends to become large the moment somebody asks for retention, replication, and three consumer groups.

The basic transaction is pleasantly ordinary: a producer writes to a topic, and a consumer reads through a subscription. The important wrinkle is that a subscription has its own durable position, called a cursor. Two subscriptions can read the same topic without racing each other. One may process orders while another feeds analytics. This is the part that prevents the usual queue argument from escaping its box and becoming an architectural meeting.

Pulsar also gives every persistent topic an address shaped like tenant, namespace, and topic. The tenant is an administrative boundary. The namespace groups topics under shared policies. This means names carry authority and operating rules, not decorative folder structure. It is handy, and it is also why choosing names after the system is busy has all the charm of changing road signs during rush hour.

The other idea worth keeping is the split between brokers and BookKeeper. Brokers accept client traffic, own topics, and dispatch messages. BookKeeper stores the durable ledgers. As a result, serving pressure and storage pressure can grow separately, and topic ownership can move without moving all the data. The components remain separate failure domains, because reality enjoys options.

Acknowledgments advance each subscription cursor. Messages not acknowledged become backlog; failed processing can trigger redelivery. That makes duplicate delivery a normal design condition, not an accusation. Retention, expiry, and tiered storage answer different questions about how long messages remain available, so they should not be configured as if they were three enthusiastic names for the same switch.

Read the intro for the full architecture and its limits. Use the slides when you need the relationships at a glance. Keep the cheatsheet nearby for subscription behavior, ordering boundaries, and operational signals. The exercise turns the independent-cursor model into something visible in a local standalone run. After that, the reference links are the right place for exact commands, policies, and production details.

Don't Panic — Apache Pulsar Fundamentals

Relevant careers