diff --git a/Rewritten-docs.md b/Rewritten-docs.md
index 510cad5..509942f 100644
--- a/Rewritten-docs.md
+++ b/Rewritten-docs.md
@@ -1540,8 +1540,25 @@ enough to implement in low-level backend components. That also means this
 feature is visible and can be exploited but from our points of view it seems as
 appropriate compromise in simplicity.
 
-@todo: where is stored which workers can be used by supervisors and which runtimes are available, describe possibilities and why is not implemented automatic solution
-
+Next thing relating backend management is storing its current state. This namely
+concerns which workers are available for processing with what hardware and which
+languages can be used in exercises. Another step is overall backend state like
+how many jobs were processed on some particular worker, workload of broker and
+workers, etc. The easiest solution is to manage these information by hand, every
+instance of API has to have administrator which would have to fill them. This of
+course includes only currently available workers and runtime environments,
+backend statistics cannot be provided this way.
+
+Better solution is to let these information update automatically. This can be
+done two ways either it can be provided by backend on-demand if API needs them
+or backend will send these information periodically to API. Things like
+currently available workers or environments are better to be really up-to-date
+so this can provided on-demand if needed. Backend statistics are not necessary
+stuff which can be updated periodically. But it really depends on the period of
+updates, if it is short enough then even available workers, etc. could be
+updated this way and be quite up-to-date. However due to lack of time automatic
+refreshing of backend state will not be implemented in early versions but might
+be implemented in next releases.
 
 ### Web-app