Added relevant notes to README.

README.md

@@ -29,3 +29,23 @@ Bonus: At this intersection north bound traffic has a green right-turn signal, w
 
 Note: Code will be evaluated not just for function, but on the quality of the code. 
 
+# Design
+
+## Algorithmic Assumptions
+
+The problem clearly specifies a kind of timed "simulation" with a decoupled front- and back-ends.  The problem has been approached on that basis.
+
+Additionally:
+
+- The algorithm uses the term `period` to denote specific timing profiles (e.g. off-peak vs peak period).  Within each `period` is a single implicit `sequence` that itself is comprised of a set of timed `states` that each fully specify the colour of each light.  These are stored in JSON format in the file `periods.json`.
+- The problem description does not specify behaviour on period change (i.e. transitioning from normal timing to period timing).  One would assume that an instantaneous change would easily create unpredictable and unsafe conditions for any hypothetical drivers, and so in this implementation the current full "cycle" is allowed to complete before transitioning to the next period.  For this example, a full cycle should not last longer than approximately 80 seconds and therefore this is the expected maximum delay between period transitions.
+
+## Environment and Infrastructure
+
+The wording of the problem description clearly implies the use of C#/.NET, however given my lack of up-to-date knowledge with modern C# frameworks I have chosen Python/Django instead.  Django is a modern web framework for Python that includes many more features than are required for this simple project, but again has been chosen for familiarity.  A web front-end was chosen due to the broad use of HTML/CSS/JavaScript and the ease with which it can be changed or updated according to need.  It would also lend itself particularly well to a scenario where the front- and back-ends would exist on different machines.
+
+However, despite it's large feature set, Django has no native support for long background threads (though modern versions have some asynchronous call support).  For this purpose it is generally recommended to use the Celery library which then communicates with the main Django server via multiprocess pipes.  This is, however, overkill for this problem and so a simple thread is used instead.  This however means that the simulation thread relies on the Django webserver for its own existence.  In an Enterprise environment, it would be more desirable to have the traffic light control to operate independently, which would then encourage the use of a separate process such as provided by Celery.
+
+The UI is a simple web page that calls polls for updates from the server.  Due to the use of locks to avoid race conditions, this can induced minor delays (milliseconds at worse) in the processing and updates of traffic light information in the simulation thread.  The main loop is designed in such a way that this will not cause cumulative delays in traffic light timing.  However, it is worth considering that another approach may be desirable (such as pushed client updates rather than polling) if, for instance, many clients were expected to be making simultaneous requests of the server.
+
+