Identity/PersonaProfileServer
< Identity
Jump to navigation
Jump to search
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
- How much data are we storing?
- What is the usage pattern? (only accessed at registration? not written often?)
- How are we handing back the data?
- 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?
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)