Revision as of 21:15, 2 May 2012

Warning: These are just rough notes. We are in the early stages of our discussions with ops, so this will definitely change.

Description

different domain for profile server to scale it out differently
some kind of data storage (MySQL, but with generic key/value schema)
profile data will be key-wrapped
from an ops point of view, it's better to spend lots of CPU optimizing images at upload time then to serve unoptimize images

don't want to be a CDN for images (to prevent abuse -- "persona profile filesystem")
we probably don't want to store arbitrary key-value store for users
planning on moving very quickly from labs to prod: it will take about a quarter to move once we say we're ready

What is the maximum amount of data that can be stored per user?
Are we storing arbitrary keys or are only well defined keys going to be allowed?
How often is this data accessed? What is the write pattern? What is the read pattern? (only accessed at registration? not written often?)
How are we handing back the data?
What kind of database will we use?

What does the API look like?
If we launch as an alpha service, how do we handle migration from alpha to beta to release?

Can other services be attached to this DB?
What is our timeline? What is the data that we are going to use to decide when this is going to come out of labs and into production?
What is the data SLA? Where does data need to be backed up?

What happens when the profile server is down? Does BrowserID sign-in depend on it? (hopefully not)
Can we push image resizing / optimizing to the client?

Get some answers for the questions above
Look at lloyd's scaling to 1M user wiki page and do something similar (assume everybody is uploading huge pictures we have to resize)

@@ Line 16: / Line 16: @@
 = Questions =
-* How much data are we storing?
+* What is the maximum amount of data that can be stored per user?
-* What is the usage pattern? (only accessed at registration? not written often?)
+* Are we storing arbitrary keys or are only well defined keys going to be allowed?
+* How often is this data accessed?  What is the write pattern?  What is the read pattern?  (only accessed at registration? not written often?)
 * How are we handing back the data?
+* What kind of database will we use?
+* What does the API look like?
+* If we launch as an alpha service, how do we handle migration from alpha to beta to release?
+* Can other services be attached to this DB?
+* What is our timeline?  What is the data that we are going to use to decide when this is going to come out of labs and into production?
+* What is the data SLA?  Where does data need to be backed up?
 * What happens when the profile server is down? Does BrowserID sign-in depend on it? (hopefully not)
 * Can we push image resizing / optimizing to the client?