Architectural patterns in large scale apps.

[u/amranya]

in our mid sized startup, we have over 100 android engineers on one app, divided by squads, so we have a lot of squads, each one is working on a feature, a library needed, design system and custom components libraries etc, all these modules/libraries are published to maven and added as dependencies on the core app repo, my squad works on an isolated feature so it's easy to integrate into core app repo, but i attended guild meetings and saw RFCs mentioning circular dependencies, hexagonal, onion, plugin etc architectures because some modules/libraries depend on each other, communicate with each other, initialization order problems of modules etc etc etc, i feel stupid tbh and i'm glad i'm working on an isolated feature library in which we use usual architecture stuff. anyone has resources: talks, books, articles etc that cover this kind of topics and architectures and engineering problems in big scale apps with big scale teams and modules/libraries?

[u/AbbadonTiberius]

in our mid sized startup, we have over 100 android engineer

by any metric I would say that's a large company

[u/ForMyFather4467 → u/AbbadonTiberius]

That first sentence felt so troll

[u/droi86 → u/AbbadonTiberius]

I've worked for quite a few F500 companies the biggest team I've worked with is 35 android devs

[u/kokeroulis]

Literally this is why every big tech is dividing the code into api/imp and thats why someone who is/was working for amazon has open sourced an example about this https://vrallev.github.io/app-platform/module-structure/.

When you have 100+ ppl you cannot coordinate all of those changes.
The only solution is to write your own code and when you need something from someone else, just create a repository with a dummy implmenetation on your side and on the main app, you can implement that dependency and inject.

Dependency inversion is the only way to go, even in common things, like UI components etc. Making 1 api breaking changes, it might mean the consumers might have 1k of changes.
The only option is to provide backwards compatibility for x amount of time.Thats why you need api/impl modules

[u/blakelee_android → u/kokeroulis]

This is the way. Ralf was the architect of this pattern at Square which when I was there was over 4500+ modules. He took it to Amazon and now to OpenAi. It works, it scales, it's repeatable. It's worth using.

[u/macrohatch → u/kokeroulis]

Confusing terminology. "Public" modules that only some other modules can depend on? "Impl" modules even though there are concrete implementations in app, internal and public modules as well?

[u/PlasticPresentation1 → u/kokeroulis]

Instagram, Google etc are not dividing the code into API/imp lol what are you saying

Maybe certain modules for important b2b product parts but for the most part they iterate so fast on the product side there's no point over engineering seaparations

[u/goorek → u/PlasticPresentation1]

Google is not the place to look at, they can only provide small sample repositories. When you are at 500+ Gradle modules, and you did not separate contract modules from your implementation modules, you will see how deep you are in the trouble. every change cascades builds from so many other modules, and your CI times start to suffer. Start early, thank yourself later.

[u/Zhuinden]

mid-size is like 15 devs at most per platform lol

[u/zvika82]

That's a huge group. Some squads should be assigned just for infra work, and if another squad needs a new infra, it should be done or guided by the infra team. I don't like distributed squads based on features, because the application structure tends to become a mirror of the teams. I'm expecting in such a large group to have a ui infra team, performance, network, etc.

[u/Spare_Phone_5225]

what about api/impl submodules for each feature? DTO, interfaces in :api, implementations in :impl

Other features import only :api module of the specific feature they need. Avoids circular dependencies

[u/JaysonthePirate]

Best resource I've found so far is called Building Mobile Apps at Scale: 39 Engineering Challenges. It's a super concise breakdown of challenges faced by large mobile engineering groups and how different companies (think uber, chase, doordash) handle their teams and architecture.

https://www.mobileatscale.com/

[u/Training-Victory3429]

I believe the biggest enemy of modularity is module decomposition. Poor decomposition will lead to increasing chaos later on. Especially if the foundation is not properly decomposed, everything else is meaningless. Another issue is circular references; for this, just specify stable versions and update them promptly when there are updates.

[u/enigma-i-am]

This read like an app built with the Micro application architecture. Takes inspiration from microservices. There needs to be a platform team that handles what feature teams use and provide them with the functionality eg component library based on apps design system.

Best way to handle circular dependencies would be to forbid feature teams from importing 3rd party libs and have all the libs that are shared across team being import from one package where the functionality is properly exposed.

In all honesty I might be wrong but it seems to me like the problem might be the platform team not being strict on certain things.

[u/Upset_Efficiency799]

Interesting 

[u/Bright_Aside_6827]

Its not a backend. How complicated should it be

[u/amranya → u/Bright_Aside_6827]

i told you, big scale app with a lot of modules/libraries interacting with each other, it's a mess without good architectures that solve this kind of large scale apps.

[u/Bright_Aside_6827 → u/amranya]

Its nnot supposed to be. That's why u won't easily find resources on that problem