5 ms·

Anyone else reading this and being quite happy that they're not working at this scale?

mystified5016 2y ago
Any time I read anything about any web-adjacent technology I'm incredibly thankful that I don't work anywhere near that industry. Embedded can be complex, but web stuff is just a Lovecraftian nightmare in comparison
- milesvp 2y ago
  I have stared into the abyss and seen the eyes of cthulu. I am much happier writing embedded drivers than I was trying to make sense of why previous devs thought it was a good idea to move bounded tunable server side api calls to the client, allowing it to effectively write arbitrary sql calls across multiple databases.
  - qudat 2y ago
    Iteration speed is significantly fast on the client. Perf is an afterthought — for better or worse
    - swyx 2y ago
      spoken like someone who doesnt deploy clients at discord scale? the 200 backend nodes surely update significantly faster than the hundreds of millions of clients.
  - artursapek 2y ago
    Sounds like a fun time lol
  - bdcravens 2y ago
    Fortunately the web is starting (very slowly) to return to sanity, pushing back towards the simpler server-rendered pattern with Javascript being relegated to specific use cases.
    - Aeolun 2y ago
      I really like the client rendered UI part. It’s a lot more efficient than sending the whole page again every time.
      - gonzo41 2y ago
        But you can cache the whole server side page and the cost is once. Whereas if you have the client side do the render then every client wears the cost.
        iknowstuff 2y ago
        You usually can't because of users who are signed in needing slightly different pages etc.
        bdcravens 2y ago
        While not as fast as a purely client cached page, the server can selectively cache content, even when some bits of the page are dynamic.
        asynchronous 2y ago
        We can also cache some of the dynamic JavaScript, depending on the scenario but your point stands.
        bdcravens 2y ago
        Which becomes a far more important issue when dealing with bandwidth or CPU constrained devices, or artificially imposed constraints due to data usage costs.
        Aeolun 2y ago
        That’s your generation that happens once. The browser still needs to render it. Sure, rendering it on the client may cost the client a bit more, but the client generally has the computational power to spare.
      - 2y ago
Twirrim 2y ago
But that's where the really fun and complicated problems are. The ones that really make you stop and think, and not just think, but be creative. 95% of the work is still the same "treading in well trod paths", same old same old tech work, but that 5% is really something.
- pavel_lishin 2y ago
  I think I can understand the appeal, but it's just not there for me. I have enough complicated problems outside of work, some of which are even fun to solve.
- Olreich 2y ago
  This was a “double-pump” migration to a faster database and building a caching service. There’s nothing particularly fancy or creative about their solutions. The migration efforts and working out issues with the reverse table scan were probably way more creative, but they didn’t get into that unfortunately.
wavemode 2y ago
I don't mind scale. I mind the bureaucracy and promotion-driven-development that comes with working in a bloated engineering org.
- pm90 2y ago
  +100 Many companies have products that operate at “scale”. They manage to do so with pretty boring techniques (sharding, autoscaling) and technologies (postgres, cloud storage). Because of the insane blog driven tech culture, many of these teams get questioned by clueless leadership (who read these blogs) and ask why the company isn’t using cassandra / some other hot technology. And it always causes much consternation and wastage.
  - rnts08 2y ago
    Anyone wanting to introduce $new/$other language, database, library, deployment system, build system into a large enough system that doesn't solve any actual problem is a nightmare for someone working at this scale. I don't mind the scale, I like it. I don't like having to fend off questions and complaints why we aren't deploying the latest shiny new thing in our core this week.
  - secondcoming 2y ago
    Well we use Cassandra (actually ScyllaDB) because Redis no longer cut it.
est 2y ago
I am happy that I dont have to deal with this. I am sad that my business aren't as big as this scale.
deleted 2y ago
[deleted]
Aeolun 2y ago
Honestly, 77 nodes doesn’t sound like a terrific scale? The more I scale things up, the more I realize that the tone of the problems doesn’t really change. You just get more layers to your data structures.
twelve40 2y ago
I'm happy I'm currently not working at this scale. I'm not happy when idiots (including one of our self-important ex-Google VP's) set this as a benchmark for backend interviews (for careers that 99% likely will never come close to such problems).

Any time I read anything about any web-adjacent technology I'm incredibly thankful that I don't work anywhere near that industry. Embedded can be complex, but web stuff is just a Lovecraftian nightmare in comparison

milesvp 2y ago
I have stared into the abyss and seen the eyes of cthulu. I am much happier writing embedded drivers than I was trying to make sense of why previous devs thought it was a good idea to move bounded tunable server side api calls to the client, allowing it to effectively write arbitrary sql calls across multiple databases.
- qudat 2y ago
  Iteration speed is significantly fast on the client. Perf is an afterthought — for better or worse
  - swyx 2y ago
    spoken like someone who doesnt deploy clients at discord scale? the 200 backend nodes surely update significantly faster than the hundreds of millions of clients.
- artursapek 2y ago
  Sounds like a fun time lol
- bdcravens 2y ago
  Fortunately the web is starting (very slowly) to return to sanity, pushing back towards the simpler server-rendered pattern with Javascript being relegated to specific use cases.
  - Aeolun 2y ago
    I really like the client rendered UI part. It’s a lot more efficient than sending the whole page again every time.
    - gonzo41 2y ago
      But you can cache the whole server side page and the cost is once. Whereas if you have the client side do the render then every client wears the cost.
      - iknowstuff 2y ago
        You usually can't because of users who are signed in needing slightly different pages etc.
        bdcravens 2y ago
        While not as fast as a purely client cached page, the server can selectively cache content, even when some bits of the page are dynamic.
      - asynchronous 2y ago
        We can also cache some of the dynamic JavaScript, depending on the scenario but your point stands.
      - bdcravens 2y ago
        Which becomes a far more important issue when dealing with bandwidth or CPU constrained devices, or artificially imposed constraints due to data usage costs.
      - Aeolun 2y ago
        That’s your generation that happens once. The browser still needs to render it. Sure, rendering it on the client may cost the client a bit more, but the client generally has the computational power to spare.
    - 2y ago

Twirrim 2y ago

But that's where the really fun and complicated problems are. The ones that really make you stop and think, and not just think, but be creative. 95% of the work is still the same "treading in well trod paths", same old same old tech work, but that 5% is really something.

pavel_lishin 2y ago
I think I can understand the appeal, but it's just not there for me. I have enough complicated problems outside of work, some of which are even fun to solve.
Olreich 2y ago
This was a “double-pump” migration to a faster database and building a caching service. There’s nothing particularly fancy or creative about their solutions. The migration efforts and working out issues with the reverse table scan were probably way more creative, but they didn’t get into that unfortunately.

wavemode 2y ago

I don't mind scale. I mind the bureaucracy and promotion-driven-development that comes with working in a bloated engineering org.

pm90 2y ago
+100 Many companies have products that operate at “scale”. They manage to do so with pretty boring techniques (sharding, autoscaling) and technologies (postgres, cloud storage). Because of the insane blog driven tech culture, many of these teams get questioned by clueless leadership (who read these blogs) and ask why the company isn’t using cassandra / some other hot technology. And it always causes much consternation and wastage.
- rnts08 2y ago
  Anyone wanting to introduce $new/$other language, database, library, deployment system, build system into a large enough system that doesn't solve any actual problem is a nightmare for someone working at this scale. I don't mind the scale, I like it. I don't like having to fend off questions and complaints why we aren't deploying the latest shiny new thing in our core this week.
- secondcoming 2y ago
  Well we use Cassandra (actually ScyllaDB) because Redis no longer cut it.

est 2y ago

I am happy that I dont have to deal with this. I am sad that my business aren't as big as this scale.

deleted 2y ago

[deleted]

Aeolun 2y ago

Honestly, 77 nodes doesn’t sound like a terrific scale? The more I scale things up, the more I realize that the tone of the problems doesn’t really change. You just get more layers to your data structures.

twelve40 2y ago

I'm happy I'm currently not working at this scale. I'm not happy when idiots (including one of our self-important ex-Google VP's) set this as a benchmark for backend interviews (for careers that 99% likely will never come close to such problems).