diff --git a/Rewritten-docs.md b/Rewritten-docs.md
index 9c1c4e1..c98854d 100644
--- a/Rewritten-docs.md
+++ b/Rewritten-docs.md
@@ -355,7 +355,9 @@ Developing project like ReCodEx have to have some discussion over implementation
 
 #### General backend implementation
 
-@todo: backend: what should be the structure, how many components and which one, mention scalability possibilities of current solution
+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.
+
+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 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 distribution, latter execution. These components should be enough to fulfil all above said, but for the sake of simplicity and better communication gateways with frontend two other components were added, 'fileserver' and 'monitor'. Fileserver is simple component whose purpose is to store files which are exchanged between frontend and backend. Monitor is also quite simple service which is able to serve job progress state from worker to web application. These two additional services are on the edge of frontend and backend (like gateways) but logically they are more connected with backend, so it is considered they belong there.
 
 @todo: what type of communication within backend could be used, mention some frameworks, queue managers, protocols, which was considered
 
@@ -393,7 +395,7 @@ Developing project like ReCodEx have to have some discussion over implementation
 
 #### Monitor
 
-@todo: how can progress status can be sent, why is there separate component of system (monitor) and why is this feature only optional
+@todo: how progress status can be sent, why is there separate component of system (monitor) and why is this feature only optional
 
 @todo: monitor and what is done there, mention caching and why it is needed
 
@@ -401,7 +403,7 @@ Developing project like ReCodEx have to have some discussion over implementation
 
 @todo: communication between backend and frontend
 
-@todo: why is frontend divided into server and client part, mention possibilities of separated api
+@todo: why is frontend divided into server and client part, mention possibilities of separated api (can be used by multiple client programs - mobile/pc/web applications)
 
 @todo: what apis can be used on server frontend side, why rest in particular