DESIGN from the last couple of days

DESIGN.md

@@ -18,6 +18,16 @@ Flowing from desire for "stability":
 * thinking about resource-usage from-the-ground-up.
 
 
+CLI-first
+
+proxying should be a primitive
+    i.e. local client should be similar to servers.
+    (passing events is natural)
+
+
+built from understood/known performance characteristics 
+
+
 Solve as much client-side as possible.
 
 What you care about: "issues", not "events"
@@ -39,3 +49,38 @@ Splitting the issue-database from the organizational database?
 
 
 
+Event-based from the ground up.
+    because "duh"... this is a textbook event system
+    because stability: easier to reason about costs this way.
+    because easier to get performant: do your calculations incrementally (e.g. quota usage becomes a +=1 operation)
+
+
+
+TECHNICAL CHOICES:
+
+mysql v.s. postgres (v.s. sqlite): make an _informed_ decision
+
+
+
+NEXT UP
+
+Start building
+    motto: off the shelve and boring components, but with an architecture which takes replacability in mind
+
+    ingesting  first
+        as a simple Django app which dumps everything into a textfield (this is TSTTCPW)
+
+        this also allows for 
+
+    dogfooding becomes possible: 
+        turn on sentry-SDK and send issues your own way.
+
+    a bunch of example events are availabe in e.g. GlitchTip.
+
+install both GlitchTip and Sentry locally.
+    optie 1: met de aangeraden docker-compose
+    optie 2: the "developer" view (misschien beter als je pdb wilt kunnen doen??)
+
+
+NEXT READING SESSION: last OS version of sentry itself.
+