[HN Gopher] Noria: Dynamic, partially-stateful data-flow for hig...
       ___________________________________________________________________
        
       Noria: Dynamic, partially-stateful data-flow for high-perf web
       applications
        
       Author : mlerner
       Score  : 41 points
       Date   : 2021-12-19 16:17 UTC (6 hours ago)
        
 (HTM) web link (www.micahlerner.com)
 (TXT) w3m dump (www.micahlerner.com)
        
       | Orou wrote:
       | The author of Noria, Jon Gjengset, gave a great talk about the
       | system: https://www.youtube.com/watch?v=s19G6n0UjsM
       | 
       | The speeds achieved are impressive but you do not get
       | consistency.
        
       | awinter-py wrote:
       | +1 for anything that schematizes caching semantics
       | 
       | I've gotten this wrong so many times, and because it only bites
       | you in read-after-write scenarios, it can be difficult to catch
       | with types + tests
       | 
       | feels like there are a bunch of patterns in client-server
       | protocols that should be 'as declarative as the schema', but
       | aren't currently. caching, sync, field transformation, batching
       | rules, multi-RPC flows like oauth
        
       | fiatjaf wrote:
       | Where is the link to the code and installation steps?
        
       | maxthegeek1 wrote:
       | I could see this being very useful. The standard cache + db
       | architecture has some sharp edges that end up biting people all
       | of the time e.g. the thundering herd problem.
        
         | rubiquity wrote:
         | Not only that but your database and app are working under the
         | assumption of Read Committed or better and now by introducing a
         | cache that is out of band from your database transactions
         | you're introducing a whole slew of consistency bugs (that often
         | go undetected).
        
           | lf-non wrote:
           | I may be missing the point here, but isn't it common to
           | address this through a combination of timestamped keys[1] and
           | interleaving database and redis transactions (start redis
           | transaction, start db transaction, update db and add cache
           | operations to current trx, and finally commit db trx and if
           | it succeeds commit the redis trx, otherwise rollback the
           | redis trx.)
           | 
           | [1] https://blogcabin.37signals.com/posts/3113-how-key-based-
           | cac...
        
             | Orou wrote:
             | Is the interleaving of redis and db transactions atomic?
        
       ___________________________________________________________________
       (page generated 2021-12-19 23:01 UTC)