Scaling is usually described as a problem of coordination, and it is mostly a problem of decomposition. The events and roles that get added are visible, and the split that made them necessary is not.
What does not change
A product has one Product Backlog, one Product Goal, one Product Owner, one Definition of Done and one Increment. None of that scales with the number of teams, because all of it describes the product rather than the teams.
The Product Owner accountability is held by one person. On a large product that person cannot personally write every item, and others help with ordering, refining and talking to stakeholders. What cannot be delegated is the decision about what the product becomes, because splitting that decision produces teams pulling a single product in different directions with nobody able to settle it.
Nexus
Nexus is Scrum.org's framework for roughly three to nine Scrum Teams working from one Product Backlog. It adds a small amount of structure and changes nothing underneath.
The Nexus Integration Team is accountable for producing an integrated Increment, and it exists because integration is where scaled work actually fails. Its membership can change as the source of integration trouble moves.
Nexus adds events that mirror the Scrum ones at the level of the whole product. Teams identify dependencies before a Sprint, surface integration problems daily, inspect the integrated Increment with stakeholders once, and look at the whole Nexus in a retrospective. Refinement becomes a formal event rather than an ongoing activity, because on a scaled product the purpose of refinement is finding the dependencies before they are committed to.
Dependencies are the work
Every scaling framework provides a way to see dependencies. Seeing them is useful and it is not a solution, because two teams that must both finish before anything ships are still two teams that must both finish.
The durable move is to change the split so the dependency disappears. That usually means organising teams around parts of the product a customer would recognise rather than around technical layers, so that a piece of work has a single team that can complete it. It is slower to arrange and it removes the coordination rather than scheduling it.
An organisation that keeps adding coordination without ever changing the split converges on a large planning apparatus that produces the same integration failure later and more expensively.
Before scaling
Adding teams to a product raises the communication cost and lowers the rate at which any one decision can be made. It is worth doing when the constraint is genuinely how much can be built at once.
It is often not. When the constraint is unclear ordering, slow releases or a Product Owner without the authority to decide, more teams make each of those worse. Scrum.org's advanced material treats this as the first question, and the answer is frequently to fix the impediment rather than to scale around it.