Master Protocol Buffers for System Design

In system design interviews high level design is relatively simpler if you know the basic building blocks. For low level design you are expected to design the API interfaces. How would you do that ? A lot of people either like to talk in terms of REST apis or a programming language specific APIs.

However, I recommend candidates to master protocol buffers as a way to describe your API interfaces. Even if you plan to use REST and not GRPC, it is trivial create an adapter around GRPC to support REST interfaces. But why is ProtoBuff so important ?

Protocol Buffers are typed JSON is not.

If you are using JSON to describe your API input output, you will encounter the problem of describing types to the interviewer.

For example consider a photo object.

// Photo Object
{
  fileName: "",
  contentType: "", 
  base64EncodedImage:""
  author: { .... }
}

// Video object 
{
  fileName: "",
  contentType: "", 
  base64EncodedVideo:""
  author: { .... }
}

The problem here is that how do you communicate types of different fields ? What exactly is an authors object ? Also how do you represent the fact that Author object is similar for both Video and Photo ?

Compared to this check this

message Photo {
  string fileName = 1; 
  enum ContentType contentType = 2; 
  bytes imageData = 3; 
  Author author = 4;
}

message Video {
  string fileName = 1; 
  enum ContentType contentType = 2; 
  bytes videoData = 3; 
  Author author = 4;
}

message Author {
 long userId = 1; 
 repeated Role roles = 2; 
}

enum ContentType {
  BINARY_PNG = 1; 
  BINARY_MP4 = 2; 
}

Not only this is extremely concise, it also answers a lot of questions about the types and reusability of objects. It is also better to store protobuff in storage because they optimize a lot of storage related aspects.

If you propose to use Cloud Spanner database in GCP, then you can actually describe your database schema using protocol buffers as well.

Similarly, if you want to describe API interfaces it is much better to describe them as gRPC interfaces using protocol buffers instead of REST.

Protocol Buffers

syntax = "proto3";

service MultiMediaService {
  rpc UploadPhoto (stream UploadPhotoRequest) returns (UploadPhotoResponse) {}
  rpc UploadVideo (stream UploadVideoRequest) returns (UploadVideoResponse) {}
}

message UploadPhotoRequest {
  bytes chunk_data = 1; // Chunk of the photo data
  string file_name = 2; // Name of the photo file
  string content_type = 3; // MIME type of the photo (e.g., "image/jpeg")
}

message UploadPhotoResponse {
  string photo_id = 1; // Unique ID for the uploaded photo
  string photo_url = 2; // URL to access the photo
}

message UploadVideoRequest {
  bytes chunk_data = 1; // Chunk of the video data
  string file_name = 2; // Name of the video file
  string content_type = 3; // MIME type of the video (e.g., "video/mp4")
}

message UploadVideoResponse {
  string video_id = 1; // Unique ID for the uploaded video
  string video_url = 2; // URL to access the video
}

This avoids the problem of describing HTTP endpoints, proper HTTP methods and JSON input output. Not only this is a better design but also it makes the system design interview more efficient by saving on time.

Pitfalls

However, it is always a better idea to ask your interviewer if they have any preference between JSON and ProtoBuffs. If the interviewer is not familiar with Protocol Buffers it might only confuse them. In that case stick to JSON.