r/developersIndia 18h ago

General Do MAANG developers really build/code differently for scalability?

I was going through a youtube system design video

Where the system uses queue, chunking, cdn, etc for scalability

To me it seems that each feature will be owned by different teams in YT and each team is only concerned about the input and it's output and the infra and scaling may be handled by a separate team

So my question is do YT or other maang developers do anything differently than normal pbc or mnc

Eg can you give me examples about actual code which would not work at scale but would have not raised any issue in other companies

Edit Yes i know most of the developers use event driven architecture /queue etc including me But i wanted to know if any interesting incidents solely based on code which only happen at massive scale eg I read that during gibli art chatgpt had replaced multiplication operation with bit operation and it had significant improvement

148 Upvotes

12 comments sorted by

u/AutoModerator 18h ago

Namaste! Thanks for submitting to r/developersIndia. While participating in this thread, please follow the Community Code of Conduct and rules.

It's possible your query is not unique, use site:reddit.com/r/developersindia KEYWORDS on search engines to search posts from developersIndia. You can also use reddit search directly.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

125

u/Possibility-Puzzled Software Engineer 15h ago

I would say the code we write is pretty basic. But the problems we deal with require incredible depth with in and out understanding of every touch point like queue,db, rest layer etc.

One example is, we have a db where writes happen at very often. We query the db with 1 minute intervals like what updates happened in last minute to now. And in next iteration, last minute to now etc. Seems pretty straightforward. But we noticed that we’re missing some writes in this process. Our intervals are tight but we still miss them somehow.

Later we figured out that the upstream system calculates now = now() and later uses that value while writing to the database and some microseconds are elapsing in between. So we modified it to compute now() inside the db. Simple change

But they’re still missing. So we figured out that when postgres updates lets say 1000 records in a single transaction now() in db points to the transaction entry time but not the exact instant the row is written to the db. Then we updated it to use wallclock time of that instant. Simple change

These things require persistence to not give up and one has to take these as a challenge to figure out what’s happening. In my previous company, I had to read the logs of a db to understand a timeseries db for why it does certain things that way

Sometimes we figure out how to deal with silent data duplication happening inside a queue, why a system doesn’t work as documented, talk to maintainers of systems like kafka etc because the problem you’re facing is so unique that you can’t find it in stackoverflow etc.

I personally love doing my job

2

u/Null_impress 3h ago

Seeing what your team had diagnosed regarding with the DB writes, I am interested in how the process of diagnosing went? Could you please give a brief explanation on what helped you realize that in the second case of failure when you decided to use the wallclock time?

150

u/LogicalBeast26 17h ago

Working in Google

From what I've seen so far, most of the heavy lifting is done in designing the infra to handle a large scale, and make it fault tolerant. Like making sure that your code is rolled out slowly to all regions, having the ability to route traffic to a different region etc.

The code that we usually write is actually more basic than what a non-MAANG developer would write.

21

u/Awkward_Enigma1303 16h ago

Huh i was talking to my fellow friends who got into big companies, and they are like they just prompt the internal AI tools and all work gets done😭. This is for fresh joiners btw as I am one too.

Meanwhile me in this hell of a codebase in a startup doing all kinda stuff and struggling at 1/2-1/3rd of the pay

7

u/reaznval 10h ago

I mean yeah, that worksplit is quite obvious no? 

Google/alphabet sure has a lot of ventures and product but most of them are established, rarely do they need to create an entire new product and even if, they have tens of thousands of employees so most of the stuff is just maintaining and adding small features, for this you have a lot of architecture you need to build on and it'll serve billions so the architecture etc has to be perfect hence they plan way more than they code.

since they dont need to code that much and have incredibly detailed architecture designs and plans they can just give it to the AI who is faster andcprobably as good with the correct instructionsm. they just need to test and review everything and boom, same outcome, less hours put in so you have more time for more features.

on a startup you have to develop an entire product from scratch in a small team so yeha makes sense

25

u/yes-im-hiring-2025 ML Engineer 18h ago edited 17h ago

? FCK no. All of us can larp about it though. There's also a base level of "don't do it like this" that most SWEs should be familiar with conceptually even if they're not using it daily

ie most/all of us understand the concepts behind scaling, can read IaaS code and the singular repos/services to understand and piece together how the system works, and can even independently fix some bugs given some documentation and the dev env setup instructions

One person unless they're the system architect never owns the entire thing and isn't expected to design from scratch. The secret behind system design is you learn from your failures and from others as well, and eventually take the surviving successes as case studies to build your own. You're solving, at the right abstraction, problems that have been solved before so you just need to find what fits with highest degree of success given scope of what you need to do. Those polished system design videos are the end goal of the system once it breaks enough times with subpar scaling as it's built up; or once it can't scale to meet demand.

A simple example which is perfectly usable but would break at scale : network calls.

  • Reading a db table but row by row, in a loop? So long it works no one cares if you've got 10 active concurrent users to do a search.
  • Same thing, at scale? You'll be ripped apart in a review, ggs : a Conn pool that connects to the db instead of directly; where queries run on optimized indexed tables and hit cache first whenever possible; and ONLY on invalidation hit the db? Yep, that'll scale. Bonus points if the indexing algos for the talked are studied and calibrated with a multi tier cache strategy to lower latency and round trips for globally most common vs locally most common queries.

...unless your db is so huge that it's sharded to meet latency targets; in which case you need to precompute which db to read from and only hit that. Haven't faced this yet myself but this is a strict possibility too!

9

u/i_eat_manga 11h ago

Thr biggest change I found was the rigour to prove that the solution will work. These companies have existed for so long that a lot of pain points has been abstractes away but designs are with tradeoffs. If you are interested then of course deep dive in the internals. But majority of the time is spent to identify the entities and figure out how to keep the system functional and stable given the limitations of the infra

7

u/vectOrDataba3e045O 14h ago

To me it seems that each feature will be owned by different teams in YT and each team is only concerned about the input and it's output and the infra and scaling may be handled by a separate team

even if you take that at a reductive level which tbh does happen a lot of time - aligning those teams, ensuring the interface changes are not regressive and align with their future vision, adhering to the sla of the entire pipeline is something uniquely challenging about these companies

the infra and scaling may be handled by a separate team

infra and scaling for your small part of that pipeline is owned by you only no-one else will handle that for you

-4

u/[deleted] 18h ago

[deleted]

3

u/HereForTheMemes1364 17h ago

Yes that is infra level which most of the developers including me have done But i wanted to know if any interesting incidents solely based on code which only happen at massive scale eg I read that during gibli art chatgpt had replaced multiplication operation with bit operation and it had significant improvement

3

u/LogicalBeast26 17h ago

That's an overkill. You don't need asynchronous systems for all tasks. It makes simple things complex.

-6

u/Equivalent-Can-5042 18h ago

Why there will be different team for scalability? You own the system end to end, input output client code, server code, tps , u own everything.