diff --git a/Monitor.md b/Monitor.md
index e4daa27..73b8c31 100644
--- a/Monitor.md
+++ b/Monitor.md
@@ -21,7 +21,15 @@ Monitor is written in Python, tested versions are 3.4 and 3.5. For it's function
 
 ![Monitor message flow](https://raw.githubusercontent.com/ReCodEx/GlobalWiki/master/images/Monitor_arch.png)
 
-There are 2 threads - _Thread 1_ is main thread, which initializes all components like logger or starts the other thread and then runs the ZeroMQ part of the application. _Thread 2_ is responsible for managing all of WebSocket connections asynchronously. Whole thread is one big _asyncio_ event loop through which are processed all actions. None of custom data types is thread-safe, so all events from other threads (actually only `send_message` method) must be called within the event loop (via `asyncio.loop.call_soon_threadsafe` function). Please note, that most of the Python interpreter use GIL ([Global Interpreter Lock](https://wiki.python.org/moin/GlobalInterpreterLock)), so there is actualy no parallelism in the performance view, but proper synchronization is still required!
+Monitor runs in 2 threads - _Thread 1_ is main thread, which initializes all components (logger, ...), starts the other thread and runs the ZeroMQ part of the application - receives and parses incomming messages from broker and forwards them to _thread 2_ sending logic. _Thread 2_ is responsible for managing all of WebSocket connections asynchronously. Whole thread is one big _asyncio_ event loop through which are processed all actions. None of custom data types is thread-safe, so all events from other threads (actually only `send_message` method) must be called within the event loop (via `asyncio.loop.call_soon_threadsafe` function). Please note, that most of the Python interpreter use GIL ([Global Interpreter Lock](https://wiki.python.org/moin/GlobalInterpreterLock)), so there is actualy no parallelism in the performance point of view, but proper synchronization is still required!
+
+**Handling of incomming messages:**
+
+Incomming ZeroMQ message is received and parsed to JSON format (same as our WebSocket communication format). JSON string is then passed to _thread 2_ for sending. Each message has an identifier of channel where to send it to.
+
+If there's connected receiver on that channel id, there is separate instance _asyncio.Queue_ where ready-to-send messages are stored. Messages from that queue are sent through corresponding WebSocket connection via main event loop as soon as possible. This approach with separate queue per connection is easy to implement and guarantees reliability and order of message delivery.
+
+When there's no connected receiver for message channel id, the message is dropped with warning message in monitor's log file.
 
 ## Installation