Identity/PersonaProfileServer

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

Things to avoid

• 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

Questions

• 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?

Questions continued

• Find out number of emails per user
• Decide on a maximum image size
• Run the moocard idea past skinny

TODO

• 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)
• Talk to security folks, what needs to happen in what order?
• Talk to David Ascher and user data group to find out about data collection implications.