chp 2 - part 4:

• worry about scale when its time to worry about it, if you are startup in the early stages, worrying about scale is rather premature
• have more than 1 machine complicates and slows things down -> go down that path when you are ready
• only look at 1 order of magnitude ahead, right now you have 10 users make sure you can support a 100, when you get to a 100 look at a 1000...
• you need to see where the current bottle necks are before you optimize and scale
• linear scalability - doubling the resources doubles the load you can handle (good)
  • very rarely do you achieve more load with less cost
  • often you end up spending double for less than double the load
• vertical scaling / scaling up -> make machine bigger
• shared-memory architecture -multithreaded applications, sharing RAM
  • -ve: cost grows faster than load
• shared-disk architecture: machines that do not share RAM or CPU but storage
  • NAS: Network-attached Storage
  • SAN: Storage Area Network
  • -ve: contention and locks (think db)
• horizontal scaling or scaling out: add more machines
• shared-nothing architecture: add extra machines
  • +ve: increasing number of nodes/machines easy
  • -ve: more complicated
• magic scaling sauce: does not exists - there is no one right way to scale
• you don't have to break everything out to its own microservice, looking at where the SPOF and increased loads are are good places to start looking at where to draw microservice lines

chp 2 - part 5:

three factors to maintainability:

1. operability
   • how easy is it to operate the software, do deploys, do maintenance on machines
   • operations can cover for bad software
   • make routine tasks easy by: having docs, be predictable, reasonable defaults, self-healing, monitoring
2. simplicity
   • big ball of mud: very complicated software
   • complicated software makes it hard for developers to reason about and decreases confidence in changes
   • essential vs accidental complexity: problem is inherently complex vs due to tooling limitations
   • abstraction hides complexity

abstraction of db through sql makes sense, imo abstraction in the code tends to happen to early and instead of hiding complexity it increases complexity and reduces developer's capacity to reason about code.

if I have to maintain it I don't want it abstracted away from me

3. evolvability
   • how easy is it to evolve the system to a new state to meet new requirements
   • if changes you make are irreversible then you aren't really flexible, if you can't hit undo on too many things its not good