Added FAQ on why BigBlueButton does not store state

Author: ffdixon

_posts/2015-04-05-faq.md

@@ -621,6 +621,7 @@ Yes.
 
 See Ubuntu's documentation for [Webcam Troubleshooting](https://help.ubuntu.com/community/Webcam/Troubleshooting).
 
+
 ## Voice Conference
 
 ### Why can't others hear me in the voice conference
@@ -743,6 +744,21 @@ When looking to download a recorded session, most expect a single link to downlo
 
 In contrast, BigBlueButton does not create a video file for playback.  Video files for a three hour lecture can get very large.  Instead, BigBlueButton creates an HTML5 page that references PNG images and audio, and time indexes the PNG images against the audio to match their display in the session.  The result is the source playback files are very small and can be hosted on any web server.  The drawback is there will be a pause for the browser to download all this content, but, once downloaded, there is no more load on the web server.
 
+## Other
+
+### Why does content not persist between sessions
+
+BigBlueButton does not store any content -- such as chat, shared notes, uploaded slides, annotations, etc. -- between sessions.  When you end a meeting and start a new one, you have a new meeting with a clean slate.
+
+Starting every meeting as a new meeting is by design.  To understand why, it's helpful to think of BigBlueButton like a web server.  A web server does not hold state between requests (other than logging the request).  This makes the architecture of the web server much simpler and easier to extend: the web server can focus on serving as many requests as possible in parallel as efficiently as possible.
+
+In a similar manner, the BigBlueButton server focuses on running many parallel meetings as efficiently as possible.  If the meeting was recorded, then a separate process will later convert the saved meeting into a recording.  In contrast, if the BigBlueButton server did store state from past meetings, that storage would have to be maintained, updated, and migrated when the server is upgraded.  There would be privacy issues as well -- how to keep the stored state, and how to administer it for privacy requests (this would likely require a separate interface).  Overall, the design of the BigBlueButton would be more complex.  Also, load balancing (such as with [scalelite](https://github.com/blindsidenetworks/scalelite)) would be more difficult as every BigBlueButton server would share a central object store for all the past meetings.
+
+The API does allow for a front-end to pre-upload a presentation, which gives the moderator the ability to customize meetings with the same presentation.
+
+In short, this stateless approach makes the overall architecture of BigBlueButton much simpler, and simple is good for focusing on speed, stability, maintainability of code, privacy, and focusing resources on building out features important to instructors.
+
+
 # Developing BigBlueButton
 
 ## Setup