[HN Gopher] The Fundamental Mechanism of Scaling
       ___________________________________________________________________
        
       The Fundamental Mechanism of Scaling
        
       Author : yagizdegirmenci
       Score  : 23 points
       Date   : 2021-07-17 11:20 UTC (1 days ago)
        
 (HTM) web link (brooker.co.za)
 (TXT) w3m dump (brooker.co.za)
        
       | kureikain wrote:
       | This is what I came to conslusion that a system without any
       | dependencies can scale easiser.
       | 
       | For my email forwarding app (https://hanami.run), our web tier
       | can down, and even the database can down but the mail servers to
       | handle incoming emails and forward out can tolerate database
       | outage.
       | 
       | For my particular use case, the mail servers boot then load
       | entire state that they need into its cache, then write this to a
       | local LevelDB. Incoming email is persisted into this LevelDB too.
       | Then another thread will flush mail to Postgres if needed.
       | 
       | By this simple design, we can even survive data center outage
       | because the mail servers has all the state it need. Granted that
       | during the outage, no one can signed up(web tier and control
       | panel are down), but at least existing user won't be affected
        
         | Jare wrote:
         | > a system without any dependencies can scale easiser
         | 
         | This is true for teams and projects too.
        
       | michaelfeathers wrote:
       | > The fundamental tool of cloud scaling is coordination
       | avoidance.
       | 
       | Having many systems rather than one is the ultimate scaling hack.
        
       ___________________________________________________________________
       (page generated 2021-07-18 23:01 UTC)