It sounds like you are asking a question about the CAP Theorem. This says you can have two of these three properties in a distributed system: consistency, availability, and partition tolerance.

If your system prioritizes availability, the theorem says you need to give up consistency (i.e. deliver something eventually consistent instead) or partition tolerance (i.e. if some of your nodes split-brain but availability is super important so writes to the same object are accepted in both partitions, some of the writes will be lost when the split is healed).

Scalability is sortof related, but also sortof orthogonal to the CAP tradeoffs. Scalability relates more to things like parallelization (how many req/s can be handled) and minimizing latency (requests at volume are still fast). Scaling a system depends quite a lot on what kind of requests you expect. For example, if you expect writes to be rare but reads to be frequent, a cache might be a good approach to scale (support more parallel requests). If your application is write-heavy and you need writes to scale you might investigate how to parallelize the writes (sharding, for example). In both cases, there are some availability tradeoffs (what happens if a cache node is down, what happens if a primary node is down, etc). So solutions touch back on CAP theorem again.

There are also approaches using specialized data structures like CRDT that help applications navigate tradeoffs like this. CRDT-structured data is commutative by definition, so in the case of a partition the application can "heal" without data loss. While this seems to optimize for consistency, availability, and partition tolerance all at once, your app would need to constrain its data models and UX to conform to data that can be modeled as CRDT. Operational Transformation is a related approach used for collaborative text editors, etc.

Ultimately, your solution to scaling an app relates to expected behavior (what kind of requests are you scaling) and acceptable CAP tradeoffs.