diff --git a/Rewritten-docs.md b/Rewritten-docs.md
index 1d9802e..21a7669 100644
--- a/Rewritten-docs.md
+++ b/Rewritten-docs.md
@@ -781,19 +781,6 @@ approaches are equally good, final decision depends on actual case.
 
 ## Structure of the project
 
-There are numerous ways how to divide some sort of system into separated
-services, from one single component to many and many single-purpose components.
-Having only one big service is not feasible, not scalable enough and mainly it
-would be one big blob of code which somehow works and is very complex, so this
-is not the way. The quite opposite, having a lot of single-purpose components is
-also somehow impractical. It is scalable by default and all services would have
-quite simple code but on the other hand communication requirements for such
-solution would be insane. So there has to be chosen approach which is somehow in
-the middle, that means services have to communicate in manner which will not
-bring network down, code basis should be reasonable and the whole system has to
-be scalable enough. With this being said there can be discussion over particular
-division for ReCodEx system.
-
 The ReCodEx project is divided into two logical parts – the *backend* and the
 *frontend* – which interact which each other and which cover the whole area of
 code examination. Both of these logical parts are independent of each other in
@@ -817,8 +804,8 @@ progress of processing of the queued jobs and the results of the evaluations can
 be queried after the job processing is finished.  The backend produces a log of
 the evaluation and scores the solution based on the job configuration document.
 
-From the scalable point of view there are two necessary components, the one
-which will execute jobs and component which will distribute jobs to the
+To make the backend scalable, there are two necessary components -- the one
+which will execute jobs and the other which will distribute jobs to the
 instances of the first one. This ensures scalability in manner of parallel
 execution of numerous jobs which is exactly what is needed. Implementation of
 these services are called **broker** and **worker**, first one handles
@@ -885,20 +872,15 @@ protocol between these two logical parts will be described as well.
 
 ## Implementation analysis
 
-When developing a project like ReCodEx there has to be some discussion over
-implementation details and how to solve some particular problems properly. This
-discussion is a never ending story which goes on through the whole development
-process. Some of the most important implementation problems or interesting
-observations will be discussed in this chapter.
+Some of the most important implementation problems or interesting observations
+will be discussed in this chapter.
 
 ### General communication
 
 Overall design of the project is discussed above. There are bunch of components
 with their own responsibility. Important thing to design is communication of
-these components. All we can count with is that they are connected by network.
-
-To choose a suitable protocol, there are some additional requirements that
-should be met:
+these components. To choose a suitable protocol, there are some additional
+requirements that should be met:
 
 - reliability -- if a message is sent between components, the protocol has to
   ensure that it is received by target component