The current messaging system is quite reliable, since we use TCP, and messages are timestamped as they arrive, you should have reasonable assurance of order and fidelity. As a developer, you should set TTL appropriately although it is reserved for future use. Published events are throttled as they are sent from the core, and limited to a burst of 4 per second, on an average of 60 per minute, and will be dropped if you exceed that limit. Currently we don’t rate limit subscribers, but we will probably limit that to something sane like ~1000 a minute or so to avoid huge floods. Generally if you’re subscribing to your own event feed you should get everything, but you may not get all events if you’re watching the firehose.
Our initial use of TTL / events will probably be a “what was the last unexpired thing I published using this event name.” So you could subscribe 9 minutes after a 10 min TTL, and get the most recent message only kind of thing.
Down the road we may support stream resuming (send me messages since TIMESTAMP / ID), and caching, but we haven’t explored that yet, and the best way to receive an event will probably be a webhook, since that is internal / always on. There are some resource implications there, so it might take some time to find a solution that works for most of the community. 
Edit: In general, we’ve seen very good message fidelity within the cloud and between cores with good connections, and we’re adding services to fill in the gaps when your core is offline / sleeping.
I hope that helps!
Thanks,
David