| Warning: I don't actually do web startups myself, so this is based on an outsider's view of the field. Computer science provides some really awesome ways to deal with algorithmic problems... but for most startup-type applications, those problems only come into play in a few places (if that). A cool time-management webapp might have an interesting algorithm at its core that uses machine learning to auto-decide what tasks are most important (making something ridiculous up), but the rest of the app is basically just a shiny interface to a database. I really doubt the problems of scaling a CRUD webapp (at less than Facebook scale) lend themselves to good mathematical analysis. Even if they did, these apps involve lots of third-party layers glued together to put together interesting functionality, and those seem to change often enough that it's not worth even trying detailed analysis. So instead they do Fermi-problem estimates to figure out their basic scaling relationships. Then you can decide how to plug things together, decide what your basic resource constraints are (compute, memory, disk, bandwidth...) and make it easy to add those resources when your customer base expands. Edit to add: Thinking a little more, that's exactly when you'd want a set of approximate algebraic constraints, so you could decide how many customers-per-EC2-instance you could serve and how that number might change as instance count increased. Math, it's important. |
at my large company i do this every day on the embedded system i work on, which luckily is not a CRUD app. i guess i would hope they would ask me about that XD
databases can get tricky. but you're right, if something complicated like a bloom filter is used to solve subset-query it's probably in an third-party API they grabbed somewhere that handles most of the difficulty.