...
Before going deep into the details, these are the key principles/features of the messaging system, based on the user story use cases and requirements described above.
- Support both transactional and non-transactional message publishing
- Support both transactional and non-transactional message consumption
- Messages are ordered by publish time
- This helps address messages by timestamp
- Maintain the same message ordering for all consumers
- Consistent message ordering is the key to reprocess messages safely
- Easy to write tool to inspect what's inside the queue
- Each message has a unique message ID. The message IDs should be sortable as in the same order as the message ordering as seen by the consumers
- Latency must be as low as possible.
- For messages published non-transactionally, they should be available for consumption right after it is persisted in the messaging system
- For messages published transactionally, they will be persisted to the message system as close as possible to the transaction commit time
- Use either client side buffering or auxilary auxiliary payload table to minimize the "blocking" effect of non-committed transaction. See later section for the detail design.
- Consumers poll for new messages instead of pushing from the server
- This gives consumer more control
- Messages are immutable once they get "accepted" by the messaging system
- For non-transactional message, "accepted" means the message is persisted
- For transactional messages, "accepted" means the transaction of that message is committed
- Hence ordering Ordering are immutable as well
- A centralized messaging service will be provided and all messaging clients only interact with the messaging service through REST
- Multiple instances of the messaging service can be up and running at the same time for scalability
...
The message ID are also sortable by lexicographical order, which gives the exactly ordering of messages as seen by any consumer.
...