37 Comments

1. 

   @NeetCodeIO

   March 9, 2025 at 6:22 am

   Here's my original DoorDash video:
   https://youtu.be/rVBtZH8vB9E

   Here are the links Matt mentioned:
   https://christophermeiklejohn.com/publications/cmeiklej_phd_s3d_2024.pdf
   https://www.youtube.com/watch?v=zf5HH1BPN4o

   Reply
2. 

   @RafaelBattesti81

   March 9, 2025 at 6:22 am

   You lost me on your unit test coverage explanation.
   A little earlier to be honest.
   Engineering has strong principles. Raw dogging dev work, doesn’t. That’s a disservice to professional software engineering.
   If you care about your craft, as you said, you don’t do things like assert 1==1. That’s cheating.

   Reply
3. 

   @YoungGrizzly

   March 9, 2025 at 6:22 am

   22:37 yeah I don’t write unit tests during development. Tests are a marker/representation of state. So if I’m still developing the state will change. Unit tests are the very last thing I do with personal projects or tools I write at work.

   Reply
4. 

   @PouyaAtaei

   March 9, 2025 at 6:22 am

   Very hollow arguments. Matt is also impossible to follow. If you have someone at a senior level who communicates like that and with that depth, of course microservices is not gonna work for you.

   Reply
5. 

   @articb

   March 9, 2025 at 6:22 am

   stop fidgeting so much its annoying lol

   Reply
6. 

   @endgameisthejoke

   March 9, 2025 at 6:22 am

   lol I have the same cup as Matt

   Reply
7. 

   @siddhahast

   March 9, 2025 at 6:22 am

   PSDE of Doordash. Thank you for articulating the truth of the microservoces. It makes me sick when people brag about how many micro services they manage when they come to interviews without even understanding on why they do it in the first place.

   Reply
8. 

   @nagesh5374

   March 9, 2025 at 6:22 am

   Thanks

   Reply
9. 

   @nagesh5374

   March 9, 2025 at 6:22 am

   Thanks

   Reply
10. 

    @oooooooooooooooooo

    March 9, 2025 at 6:22 am

    Microservices is good for job security

    Reply
11. 

    @EbonySeraphim

    March 9, 2025 at 6:22 am

    I think this hottake has more potential to do damage than help. I worked at AWS for 9 years and can say this: the benefit of enabling more developers to work on a product, platform, or set of services and scale development effort OVER the running application running with more scaling/efficiency is where a lot of companies are and will be in perpetuity. If and when some component needs to scale in a way that microservice architecture disagrees with, it's easier to delete a remote call by integrating a local library than it is to do the opposite.

    Critically, this misses a challenge of monoliths I don't think I've heard anyone talk about but absolutely exists: assymmetric usage limits of machine resources. When your monolith application starts up, how does it scale the subsystems of the application that need CPU resources, disk IO, networking IO bandwidth, available network ports, memory space, and memory bandwidth? Does it do so based on current traffic versus limits or can it adjust to live traffic? When the live system reaches a limit and starts to fail, how efficient is it to add more hosts and they relieve that specific part of the system from bottlenecking on other hosts? Maybe you've run into # of available port issues, but CPU usage, memory, and bandwidth usages are all low. Seems costly to double the size of your fleet because you need 2x the number of ports but not even close to 2x on the other machine specs. The same inefficiency exists everywhere — maybe you need an unreasonable amount of RAM, so much disk IO/bandwidth, etc that makes your server needs far from what is commonly and cheaply available. Ultimately without microservices, certain machine limits may not be efficiently or reasonably overcome. Microservices, you get to put the software on machines exactly where they'd run more efficiently, and can horizontally scale them across more machines of the same type.

    Reply
12. 

    @brunoagatte6220

    March 9, 2025 at 6:22 am

    “People never did micro services before and tried to do the best they could”, and now micro services are tech debt. Idk, this is a weird talk to me lol

    Reply
13. 

    @Dillan-BH

    March 9, 2025 at 6:22 am

    Im betting the way google broke up a frontend monolith is by breaking it down into micro front ends.

    Reply
14. 

    @ejbeast2366

    March 9, 2025 at 6:22 am

    Build fast and break things as a mentality is a big problem for this. The social culture around that mentality being a redeeming trait that's hired on is the real problem. It stifles creativity and limits everyone to focus on speed instead of robust fundamentals first. This mentality is in everything.

    Houses used to last for 500 years, now they last a season cause they're monoliths of drywall and wires, all not up to code so now microservices; plumbers, electricians, pest control, all of them have to now get involved. To a homeowner it's an expensive lesson. For a software to stall at a hospital because the code is breaking is life threatening.

    I don't have the answer, but I think it will involve A.I. I want people using A.I tools to develop new protocols. New paradigms and processes on structure of code or deployment. Let's replace mp3 with a new version with built in DRM. What I'm seeing is people using Chatgpt to build and do the same things we've always been doing just faster because the corporations pay for faster. My point is that we have tools to help us now bypass the financial requirements that are causing all of this technical debt in the first place to finally take our time, which is a death sentence in a lot of places. The fact that it's controlled culturally too is rampant.

    Until startups get over their build fast, be first, envy complexing and brown nosing, cool and stable products can be built. The future could actually look like the future.

    Reply
15. 

    @mattsmitt00

    March 9, 2025 at 6:22 am

    So in a way, microservices allow companies to buy speed for exponentially more cost in engineers and infrastructure support.

    Seems like the microservice obsessed approach came from tech companies having too much money to solve their problems with.

    Reply
16. 

    @AMGitsKriss

    March 9, 2025 at 6:22 am

    Ignoring the "distributed monolith" thing, I don't think it's Monolith OR Microservice. There's plenty in between. As mentioned, if you need to break a monolith into 5 things to easily progress, you should. But I wouldn't call those 5 services microservices, because they're inevitably not "single task" services.

    Reply
17. 

    @potaetoupotautoe7939

    March 9, 2025 at 6:22 am

    function call vs network call. I needed to hear that. Thanks a lot

    Reply
18. 

    @yumz

    March 9, 2025 at 6:22 am

    Conway's law sums it up. It's not just release issues, it can be a variety of person related causes. The same question is asked any time you make a boundary at all – should I make this a separate class? should I make this a separate library? Should I make this a separate repository/package? Should I make this a separate service? etc. Their is a cost to pay and the tradeoff better be worth it. And Conway's law is actually a better reason than this guy gives. Security and access level clearance can be a solid reason why to break up a monolith.

    Reply
19. 

    @gast128

    March 9, 2025 at 6:22 am

    The word 'monolith' is already a frame. Single exe's have inside structure like layers, subsystems and services. If these pile of microservices are dependent on each other to function as a whole one could consider to make an executable out of it. Spares on RPC calls which are gigantic in performance compared to direct function calls. Also function calls are compile time safe (if using a proper language) which helps with the change management.

    Reply
20. 

    @JediMasterT

    March 9, 2025 at 6:22 am

    5 years as a SE. In every project I've ever been in TIME is the biggest killer of everything. Got a great idea? TIME. Need to refactor bad code? TIME. Got new requirements that change how the architecture should be designed? TIME.

    Software engineering is give me everything I want at inhuman speed because TIME.

    Reply
21. 

    @DanielDingess

    March 9, 2025 at 6:22 am

    Check out a distributed tracing model like OpenTelemetry to get around your engineering call-graph issues, so at least one of those issues is in the process of being solved.

    Reply
22. 

    @herp_derpingson

    March 9, 2025 at 6:22 am

    1. Microservices are a management innovation, not an engineering one. Agile doesn't scale. Micro-services where 5 person team "owns" a micro-service is done to streamline management. Any team beyond the size of 5 starts getting into bystander effect.
    2. Another aspect is moat. No engineer can steal all the IP the company has because he has visibility on only his own micro-service.
    3. Also, if two programmers don't get along each other, but are great engineers, you can send them to different micro-services and they don't have to interact anymore.
    4. Not all languages cost the same, the part of high performance code that needs to be written in Rust/Go is going to be significantly more expensive than the bulk of code which is just python and javascript. I was offered my manager to create a microservice in Golang but the manager said, you might be able to do it, but the next person we will have to hire is going to cost a fortune.
    5. Microservices shouldn't share databases because microservices typically doesn't share teams. You can't let different people write to the same data differently with different assumptions.

    Reply
23. 

    @aw2031zap

    March 9, 2025 at 6:22 am

    Eh everything is technical debt.
    Technical debt itself is the poor notion that you can pay it off; technical debt is like measuring the surface area of a coastline – it just grows infinitely the more you zoom in.
    Microservices are necessary when you need to de-couple a release cadence from team integrations. But it doesn't actually remove those integrations.

    Reply
24. 

    @MartinCapodici

    March 9, 2025 at 6:22 am

    This is very insightful and balanced. Thanks, guys.

    Reply
25. 

    @sitrilko

    March 9, 2025 at 6:22 am

    Commenting 4 months after, but mr. Matt should consider looking into actor models.
    Since with actor calls you don't care if the call is local to the runtime, or across a network, and at least the one framework I've used (Akka) does fully support that.

    Now ofc. there are pitfalls and drawbacks with this style, just as with anything, but throwing out there the idea.

    Reply
26. 

    @FelipeNogueiradeSouza

    March 9, 2025 at 6:22 am

    I like how software engineers find an interpretation issue with well consolidated literature and blame the literature asap. Fuck Clean Architecture, microservices and DDD, because we did something wrong here while using the theory

    Reply
27. 

    @jeff55555

    March 9, 2025 at 6:22 am

    Microservices should have never been a thing. The industry was moving towards SOA already, which guided a teams to build services that matched the organisational structure in a course grained and well considered manner.

    Microservices took the idea of independantly deployable units from SOA and shattered it into a thousand pieces.

    Reply
28. 

    @FockewulfAz

    March 9, 2025 at 6:22 am

    I had an interview with DoorDash at the end of 2018, but I never fully understood their hiring philosophy. The interview process consisted of multiple stages: an algorithm-focused round, a coding skills assessment, and finally, a system design interview with their architect.

    From my experience, the interview was not designed to truly evaluate practical coding skills or real-world experience. Instead, it seemed to emphasize memorization of algorithms and standard problems commonly found online. While system design was covered in the final round, the overall process felt disconnected from assessing a candidate's ability to solve real engineering challenges.

    At the end of my interview, I asked the architect why they were hiring so many developers. He explained that they were struggling with significant backend performance issues and were attempting to rewrite their backend in Java. From my perspective, their approach to hiring prioritized knowledge of binary search algorithms and basic CRUD API implementations rather than the ability to diagnose and resolve real-world system issues.

    With this strategy, a company can hire thousands of engineers, yet still continuously face technical and performance challenges due to a lack of focus on problem-solving and architectural expertise.

    Reply
29. 

    @eyesopen6110

    March 9, 2025 at 6:22 am

    "microservices" are as good as "EJBS".. garbage.

    Reply
30. 

    @adamblance_nihongo

    March 9, 2025 at 6:22 am

    Thanks this was really interesting!

    Reply
31. 

    @windstalker2244

    March 9, 2025 at 6:22 am

    When they first moved to microservices, was the problem the monolith or the fact that it was written in Python?

    Reply
32. 

    @AhmetHalil-qu6ks

    March 9, 2025 at 6:22 am

    Automatic algorithms are running the show – Web3 Infinity Token is unstoppable!

    Reply
33. 

    @BERNARDOSteadman

    March 9, 2025 at 6:22 am

    I've been seeking a standout investment opportunity, and Web3 Infinity Token fits the bill. It has the potential to exceed all expectations.

    Reply
34. 

    @ChrystalCherry-d8t

    March 9, 2025 at 6:22 am

    Web3 Infinity Token is a project that aligns with my investment strategy. Its strong community support and forward-thinking approach give me confidence.

    Reply
35. 

    @SibelAyse-y6w

    March 9, 2025 at 6:22 am

    Doubters will regret ignoring Web3 Infinity token 's AI management

    Reply
36. 

    @AudreyTennant-m3g

    March 9, 2025 at 6:22 am

    Web3 Infinity Token is the safest altcoin ever since its automatic algorithms stop paper hands, bot transactions, and bear markets. It will certainly hit $10 in no time.

    Reply
37. 

    @NESTORPfeiffer

    March 9, 2025 at 6:22 am

    I'm sure Web3 Infinity token will hit double digits in Q3 Current SOL price: $192.79

    Reply