diff --git a/Rewritten-docs.md b/Rewritten-docs.md
index ee74a1c..7218d81 100644
--- a/Rewritten-docs.md
+++ b/Rewritten-docs.md
@@ -812,6 +812,16 @@ server side based on the inputs from the user. This decoupling gives us the
 ability to create multiple client side tools which may address different needs
 of the users.
 
+One possible configuration of ReCodEx system is ilustrated on following picture,
+where thete is one shared backend with three workers and two separate instances
+of whole frontend. This configuration may be suitable for MFF UK -- basic
+programming course and KSP competition. But maybe even sharing web API and
+fileserver with only custom instances of client (web app or own implementation)
+is more likely to be used. Note, that connections between components are not
+fully accurate.
+
+![Overall architecture](https://github.com/ReCodEx/wiki/blob/master/images/Overall_Architecture.png)
+
 The frontend developed as part of this project is a web application created with
 the needs of the Faculty of Mathematics and Physics of the Charles university in
 Prague in mind. The users are the students and their teachers, groups correspond
@@ -913,6 +923,12 @@ and testing, and it is understood by programmers so it should be easy for a new
 developer with some experience in client-side applications to get to know with
 the ReCodEx API and develop a client application.
 
+To sum up, chosen ways of communication inside the ReCodEx system are captured
+in the following image. Red connections are through ZeroMQ sockets, blue are
+through WebSockets and green are through HTTP(S).
+
+![Communication schema](https://github.com/ReCodEx/wiki/raw/master/images/Backend_Connections.png)
+
 ### Broker
 
 The broker is responsible for keeping track of available workers and