Honestly, my suggestion is to find a reasonably simple use case and to create a quick sketched architecture.
For example, draw out an architecture where you take input data (emails or whatever), queue it up, and have workers operate on it outputting analytics concurrently. It is a fairly common and reasonably simple (at least initially) use case to help you work through the types of issues, like communication drops/lag, caching, queue contention, processing concurrency etc. From there you can either write up some code to implement it in a simple form or start asking more specific questions on specific forums. e.g. if you select Rabbit MQ as the queue and have questions around it ask on their forum, if you use Ruby or Node or .NET etc, ask on those forums for specific issues or ideas.
My 2 cents is nothing makes you learn how/why better than trying to do it and having success and failures teach you where to go. And of course, researching and asking questions to avoid repeating preventable issues/mistakes is always smart. There are a number of reference architectures you can find online as well. Study them to find the weaknesses and strengths (see what others said too), the more you do that the more you will learn what to look for.
EDIT: below
I suggest my example or one similar over your initial idea simply to remove some complexity so you learn the concepts first. As someone else pointed out, once you add in the http component, possibly web sockets etc you are adding another layer of complexity on top of a basic distributed system itself. Hopefully I make sense here, cause it does in my mind.