diff --git a/Rewritten-docs.md b/Rewritten-docs.md
index 81a37a6..e0ec113 100644
--- a/Rewritten-docs.md
+++ b/Rewritten-docs.md
@@ -902,10 +902,11 @@ following options are considered:
   remote procedure calls. There are multiple implementations for almost every
   known programming language. It fits nicely into object oriented programming
   environment.
-- RabbitMQ -- RabbitMQ is a messaging framework written in Erlang. It has
-  bindings to a large number of languages and large community. Also, it is
-  capable of routing requests, which could be handy feature for job
-  load-balancing.
+- RabbitMQ -- RabbitMQ is a messaging framework written in Erlang. It features a
+  message broker, to which nodes connect and declare the message queues they
+  work with. It is also capable of routing requests, which could be a useful
+  feature for job load-balancing. Bindings exist for a large number of languages
+  and there is a large community supporting the project.
 - ZeroMQ -- ZeroMQ is another messaging framework, which is different from
   RabbitMQ and others (such as ActiveMQ) because it features a "brokerless
   design". This means there is no need to launch a message broker service to
@@ -917,12 +918,20 @@ following options are considered:
 
 CORBA is a large framework that would satisfy all our needs, but we are aiming
 towards a more loosely-coupled system, and asynchronous messaging seems better
-for this approach than RPC. RabbitMQ seems nice with great advantage of routing
-capability, but it is a quite heavy service written in language no one from the
-team knows, so we do not like it much. ZeroMQ is the best option for us, even
-with the drawback of having to implement a load balancer ourselves (which could
-also be seen as a benefit). However, all of the three options would have been
-possible to use.
+for this approach than RPC. Moreover, we rarely need to receive replies to our
+requests immediately.
+
+RabbitMQ seems well suited for many use cases, but implementing a job routing
+mechanism between heterogenous workers would be complicated -- we would probably
+have to create a separate load balancing service, which cancels the advantage of
+a message broker already being provided by the framework. It is also written in
+Erlang, which nobody from our team understands. 
+
+ZeroMQ is the best option for us, even with the drawback of having to implement
+a load balancer ourselves (which could also be seen as a benefit and there is a
+notable chance we would have to do the same with RabbitMQ). It also gives us
+complete control over the transmitted messages and communication patterns.
+However, all of the three options would have been possible to use.
 
 ### Frontend - backend communication