Hello, there! 

In software development, the end result is the sum of our choices (solo or as a team).

Every choice we made (e.g. technical decisions, prioritizing technical tasks, prioritizing features) is about choosing between trade-offs.

CAP theorem describes just that: what are the options and how to make the best choices for your app based on the trade-offs between consistency, availability, and partition tolerance.

What is CAP theorem?

According to this IBM article, the CAP theorem states that any distributed data store can provide only two of the following three guarantees:

Consistency

— Consistency means that all clients see the same data at the same time, no matter which node they connect to. 

— For this to happen, whenever data is written to one node, it must be instantly forwarded or replicated to all the other nodes in the system before the write is deemed ‘successful.’

Availability

— Availability means that any client making a request for data gets a response, even if one or more nodes are down.

— Another way to state this — all working nodes in the distributed system return a valid response for any request, without exception.

Partition tolerance

— A partition is a communications break within a distributed system — a lost or temporarily delayed connection between two nodes. 

— Partition tolerance means that the cluster must continue to work despite any number of communication breakdowns between nodes in the system.

What is a node? 

Well, pretty much everything: backend services, backend’s data storage, and every device that runs the front-end – in our case, the mobile app.

Knowing this, you should think about the business use-cases that the app and platform as a whole tries to solve.

– Do you care about having the latest data available all the time? Then optimize for consistency.

– Is it important that the services are available all the time? Then optimize for availability.

– Every node should be “up and running”? Then emphasize for partition tolerance.

By understanding this theorem, you’ll be better equipped to have a “bird’s-eye” view over the entire platform to create more robust and reliable app experiences.

In this post, I’ll be focusing on online-first and offline-first strategies.


Offline-first and online-first

Online-first mobile apps

Online-first apps are designed with the assumption that the user will have a consistent and reliable internet connection. 

They prioritize real-time data syncing between the client and server to provide a seamless and up-to-date user experience.

However, online-first apps may struggle to provide a satisfactory experience when users encounter network issues or low connectivity.

An example of when an online-first is a preferable approach (for the entire app or for core features) is when developing a retail/eCommerce app. The users need to be online to complete a purchase. Then, other users need to be online to see the latest availability.

Consistency is the key to great user experience in online-first mobile apps

Offline-first mobile apps

On the other hand, offline-first apps assume that users may not always have access to a reliable internet connection. They prioritize local data storage and operations, syncing data with the server when the connectivity allows for it.

Offline-first apps offer a smooth user experience regardless of network conditions, but they can face challenges in keeping data consistent across devices. 

For example, a news app is a good fit for the offline-first approach. Users should be able to download articles or news stories for offline reading, they can still access and engage with the content even when they don’t have a reliable internet connection.

Offline-first apps should prioritize availability to ensure a smooth user experience

In real-life however, it’s essential to strike a balance between providing offline capabilities and ensuring that users receive the most recent data in their apps.

Ok, maybe a user cannot purchase without an Internet connection, but they could check-out the product catalogue and add items to basket.

Or maybe users can read news offline, but they are not necessary up-to-date with the latest “breaking news”.

That is why hybrid approaches, combining online-first and offline-first features, can be useful for every app. Deciding when and how means taking a step back and calculate the technical trade-offs.


Differences in Consistency, Availability, and Partition Tolerance

Understanding how the CAP theorem influences both online-first and offline-first approaches is essential for making informed decisions during the development process. 

In this section, we will compare how these two strategies handle consistency, availability, and partition tolerance.

Comparing Consistency

In online-first apps, consistency is prioritized. 

These apps rely on a constant internet connection to keep the data synchronized in real-time across all devices. As a result, the data remains consistent throughout the entire system, ensuring that users access up-to-date information. 

However, this level of consistency is dependent on a stable connection, which may not always be available.

On the other hand, offline-first apps put more emphasis on availability, sacrificing some level of consistency. 

Data is primarily stored and processed on the local device, leading to potential inconsistencies when multiple devices access or modify the same data. Developers need to implement conflict resolution strategies to handle these discrepancies when the devices eventually sync with the server.

Comparing Availability

Online-first apps rely on a consistent internet connection to ensure high availability. 

While they offer excellent performance and user experience when the connection is reliable, they can struggle in situations with poor connectivity, resulting in limited functionality or degraded performance.

Offline-first apps prioritize availability to provide a seamless user experience, even without internet access. 

By storing and processing data locally, these apps can function smoothly during network outages or in low-connectivity areas. However, this approach may result in temporary inconsistencies in data across devices until synchronization occurs.

That means strong availability through as little as possible data transfers = writes rarely fail, but the data written may not be available to all clients.

Comparing Partition Tolerance

Partition tolerance refers to the ability of a system to continue operating despite network partitioning or failures. Both online-first and offline-first apps must consider partition tolerance, but the strategies differ in their handling of network issues.

Since we’re discussing mobile-first distributed systems, the data is naturally partitioned because users have smartphones. 

Depending on business use-cases, the most important node is “the backend” because it has the data every device reads from or writes to. An exception would be when needing a device-to-device communication without a third node involved.

Online-first apps might experience reduced functionality or performance during network partitions, as they prioritize consistency and require a continuous connection to the server.

In contrast, offline-first apps are generally more partition-tolerant, as they store and process data locally. This allows them to operate independently of the server during network partitions, only syncing data when connectivity is restored.


Choosing Between Online-First and Offline-First 

Now that we have a better understanding of the CAP theorem’s implications for both online-first and offline-first mobile app strategies, it’s time to decide which approach is the best fit for your app. 

Factors to consider

  • Target user demographics and their internet connectivity
  • Core functionality of the app and its dependence on real-time data synchronization
  • Offline usability requirements
  • Development complexity and resources available

How to Determine the Right Approach for Your App

To choose the most suitable strategy for your app, evaluate your app’s needs and requirements in terms of consistency, availability, and partition tolerance.

Consider the target audience and the type of user experience you want to deliver. If your app relies heavily on real-time data synchronization and your users are expected to have a reliable internet connection, an online-first approach may be suitable.

On the other hand, if you want to ensure a seamless user experience regardless of network conditions, and real-time synchronization isn’t as critical, an offline-first approach could be a better choice. 

Keep in mind that the development process for offline-first apps can be more complex, so make sure you have the necessary resources and expertise to handle this.

For example, one of the most complex issues to solve are conflict resolutions that answer the question:Which data is the latest data?

Tips for Transitioning Between Strategies, If Needed

In some cases, you might need to transition between online-first and offline-first strategies as your app evolves or your target audience changes. 

Here are some tips to help you with this transition:

1 Plan the transition carefully, identifying potential challenges and opportunities.

2 Gradually implement offline functionality in online-first apps, or vice versa, to minimize disruption.

3 Test. A lot.

4 Communicate any significant changes to users and provide support when needed.

Conclusion

Keep these considerations in mind as you design and develop your app to ensure you deliver the best possible user experience, regardless of network conditions.

Remember, it’s crucial to continuously learn and improve your skills as a developer, so don’t hesitate to explore more resources on mobile app architecture and design.

Follow me

If you enjoy what I write, please follow my activity wherever you prefer: Dev.toMedium or on my very own blogstatic powered blog calincrist.com.

Thank you for reading! If you enjoyed this post and want to explore topics like this, don’t forget to subscribe to the newsletter. You’ll get the latest blog posts delivered directly to your inbox. Follow me on LinkedIn and Twitter/X. Your journey doesn’t have to end here. Subscribe, follow, and let’s take continue the conversation. This is the way!