Comments by "Muizz" (@muizzy) on "ByteByteGo" channel.

  1. One argument I missed here is that vertical scaling has better customisability than horizontal scaling. For example, if your box has 4GB of RAM and 2 CPU cores, but you're only running out of RAM, you can just create a box with 8GB of RAM and 2 CPU cores. Applying horizontal scaling here would mean you'd have to pay for unnecessary cores.
    28
  2. I'm biassed because I'm an Uber engineer, but the most interesting blog posts IMO are things like domain-ordiented microservice architecture, cadence, and the ledgerstore. Some of the open source work like cadence and FX are also incredible.
    19
  3. This would defeat the purpose of a lot of the benefits. The database here would become a single point of failure, which is may be an unacceptable drawback considering your applications.
    15
  4. Using monorepo tooling like bazel it's trivial to declare visibility for your packages. This ensures you don't need to worry about random imports, as each package can declare the scope of responsibility, and service specific code is not reachable elsewhere. At scale, versioning of dependencies is a really bad idea. Versions get updated for a reason, and although backwards compatibility is important, if we're fixing a security vulnerability, we need it live on all repos immediately; this is incredibly hard to do across repos but near trivial in a monorepo.
    6
  5.  @Deezedd  horizontal and vertical scaling are not mutually exclusive. As a simplified example, I can choose to scale a 100 box 1 core deployment to a 50 box 2 core deployment and vice versa.
    6
  6. Often times when you're maintaining a public project, your internal version of that project is more specialized. It's not uncommon to have an internal version, with periodic updates happening to the external version that copy some features. Public versions of projects are always in a dedicated repo, though.
    4
  7. Could be, but it has some potential simplifications. For example: In some scenarios (1:1), the quality may be requested by the client and the server-side transcoding can be omitted (almost) entirely. In most cases the number of necessary quality formats is lower and can be adjusted on the fly. Video calling also does not benefit from any CDN caching and can skip this step entirely. Basically: Video calling is just video streaming, but with a few potential optimisations due to the lower number of viewers.
    4
  8. The point they were trying to make here is that microservices for startups have a high amount of boilerplate code and other requirements which do not directly affect the wellbeing of the customer. In most early stage startups, it is critical that resources are used in the most efficient way possible, so it's often worth making the tradeoff between scalability and faster feature velocity, with the knowledge that a migration will have to happen somewhere down the line.
    4
  9. All big tech companies will have highly durable storage (not just for the code, but for everything). In terms of security it tends to be a combination of best practices: Hardware certificates, single signon, MFA, expiring tokens, etc.
    3
  10. Clearly cookies are a huge security risk; so we need to make sure that all visitors use 2FA and a custom certificate to authenticate with a distributed LDAP group while running the authentication service on a custom fork of an esoteric operating system. TempleOS should do the trick nicely.
    2
  11. People have a hard time understanding that the tooling that a company like google uses is created out of necessity for the insane scale at which they operate. Although some translate well to small scale (golang), most just add complexity where it's often unnecessary (bazel)
    2
  12.  @michaelchen1646  oh! I didn't even realize we open sourced zap!
    2
  13.  @uziboozy4540  Unfortunately, a distributed database just improves the reliability of the single point of failure, but does not eliminate it. In situations like this, a startup is often better off using an off-the-shelf database like dynamoDB or even firebase that provides a high availability SLA, often around 99.999%. If, however, your usecase requires an in-house database, and you choose a monolithic database, there are still a plethora of issues that can occur which will hurt the availability of your entire application. Examples of this include network level authentication issues, failure in registering the database, failed upgrades, data corruption, access control failures, and if you're working with PII you're opening an entirely new can of worms which can make maintaining a monolithic database infeasible.
    1
  14.  @joshuapare4304  check out cadence. It's not as widely applicable as FX, but it's so crazy good and robust that I still can't quite believe we open sourced it 😅
    1
  15.  @michaelchen1646  I believe Nilaway still has some issues with false positives, especially for more complicated / nested cases such as validation functions. Figuring out a way to do do that efficiently would be an extremely valuable contribution. See issue #212
    1
  16. If I have 30 different repos, my CI/CD team essentially needs to support 30 different pipelines. This is not scalable. Monorepos don't seek to group projects by relatedness, but to reduce platform level toil. Coupling unrelated projects and bad hirarchical design are not problems with a monorepo approach, they're just bad engineering.
    1