Data Formats for Communication

Clients and servers communicate by exchanging data using a request-response model. An essential aspect of this communication is the data format(s) used for exchanging information. This significant factor sets the difference between an effective and an inept API. One aspect of mobile System Design is the choice of a data format that both the client and server can understand conveniently and enhance the system’s performance.

The choice of data format is only the first step to a standardized information flow between the sending and receiving parties. Rapidly changing industry demands make it inevitable to change or update the chosen data formats overtime. Making changes to the server-side may also require updating the client-side. It’s relatively easy to reflect changes for the browser-based client interfaces, where a simple refresh may be enough to push the client to a newer version. But for the clients that use installed software, such as mobile applications, to interact with the service, we often use rolling updates, where the more recent version is gradually installed on the client-side. Therefore, data representation and data versioning are important concerns during design. The discussed scenario is depicted in the image below:

Choosing a data format

The best data format for a design problem is a trade-off between different factors and the features a specific format provides. In general, a format is considered to be a good choice if it supports a number of features, some of which are mentioned below.

• Human-readable: Easy to read and debug by developers.

• Low latency: Fast to transmit over the wire.

• Standardized: Follows a well-defined pattern in the industry.

• Machine-friendly: Needs less time to be processed by machines.

• Interoperable: Easy to serialize and deserialize data into different formats.

• Flexible: Easy to introduce and manage changes over time.

Choosing a suboptimal data format

Selecting a suboptimal data format for communication between the client (mobile apps) and backend can lead to increased computational overhead, unnecessary conversions, and data inconsistencies. In mobile systems specifically, it can lead to higher battery consumption and poor network efficiency.

When the frontend expects data in a specific format (Format X) but the backend provides it in a different format (Format Y), an additional conversion layer must process the data before it can be used. Overtime, outdated conversion logic can lead to data corruption, inaccuracies, and unexpected application behavior, severely affecting the user experience on mobile devices.

For instance, imagine a video streaming app expecting JSON metadata for video details, but receiving XML responses from the backend. As illustrated below, continuous conversion would be required before rendering, increasing CPU usage and delaying playback. Critical fields like video duration, captions, or resolution may become unreadable or incorrectly mapped if the API format changes without proper handling.

Choosing the right data format up front, whether JSON, Protocol Buffers (protobuf), FlatBuffers, or MessagePack, ensures that mobile apps receive data that is efficient, well-structured, and easily consumable. This is critical for responsive and battery-efficient mobile apps.

We can divide data formats into two broad ...