If you ask me what time it is, I’ll tell you (over many days of two-minute reads, apparently) how to build a watch, so let’s just embrace the horology.
We’re currently diving into understanding the interaction between funds-transfer-component and account-component.
Now, I call this publication Practical Microservices Daily, but we’re really focused on getting work to flow steadily through a development organization.
Today’s is likely going to feel like we’re splitting a pretty fine hair, but the most difficult-to-diagnose problems I’ve ever encountered stemmed from misunderstanding the subtleties in tools. So here we go.
When you send the messages in the design we’ve put together over the past few days, you’re using a class of technology called a “message store.” Specifically, we made our design anticipating that we would use Message DB, although the high-level design wouldn’t change if we were using a different message store.
Now, message stores are not the same thing as message brokers.
Examples of message brokers include Apache Kafka, NATS, AWS Kinesis, RabbitMQ (and all the other MQs). Great pieces of tech in their own rights, they exist to move messages from publishers to subscribers They are transports.
In this setup, publishers have no knowledge of subscribers, and indeed they don’t even know if any subscribers exist. Similarly, subscribers have no idea where the messages they consume originate, nor do they know if any publishers actually exist. We call this pattern pub/sub.
The essence of a message store
I’ll defer to Scott Bellware’s description:
A message transport can be made from just about any tech. A message store, however, is only ever a database.
A message store is first and foremost a database albeit one optimized for dealing with message data.
In our design, we’re not using events merely to communicate. That Deposited event in account-component is the authoritative state of a deposit occurring. This is the difference between “event-based” and “event-sourced.” All event-sourced solutions are event-based, but not the other way around.
Databases provide guarantees that transports do not. Remember the Reservation Pattern? That only worked because we’re dealing with a database that could provide optimistic locking.
Message stores organize messages into streams our sequential groups of messages related to the same “thing,” in our case account balances or transfers between accounts. That may sound like topics in Kafka, for example, but Kafka topics are more coarsely-grained than the streams we mean here. We mean a stream per account or a stream per transfer.
With that said, message stores can also provide pub/sub-style communication, the mechanics of which we’ll cover tomorrow.
