System Design #2: The Problem

Hello 👋 there!

Welcome to the second blog in the system design series. In the previous blog, we discussed the fundamental concerns of system design.

If you have any feedback or would like to start a discussion, feel free to hit me up on my Twitter @_imnaren or on LinkedIn. I’m always down for a good chat.

In this blog, we will discuss one of the most critical steps in the system design process, which is analysing The Problem itself. Many engineers, even experienced ones, make the mistake of jumping into solutions without thoroughly analysing the problem statement.

Analysing the problem statement is a crucial step in the process, as it helps identify the key requirements and constraints of the system and influences the design decision. Getting this step wrong can lead to an expensive journey of course correction.

Some of the essential aspects to consider when analysing any problem statement include:

• Stakeholders — Identify the stakeholders who will be impacted by the system, such as end-users, administrators, managers, and other relevant parties. Understanding the needs and expectations of stakeholders is essential in designing a system that meets their requirements. For example, in a ride-sharing application, end-users expect a simple and user-friendly interface, whereas administrators require real-time data on driver and rider activity.
• Latency — Latency is the time it takes for a packet of data to travel from its source to its destination. Knowing the required latency for your system is critical for making design decisions. In some systems, lower latency is non-negotiable, such as in an online streaming service, where any delay in video or audio can lead to a poor user experience. In contrast, a system that processes non-time-sensitive data, such as a batch processing system, can tolerate higher latency.
• Throughput — Throughput refers to the rate at which data is transmitted over a communication channel or processed by a computing system. High throughput is desirable in a file transfer application, as it allows files to be transferred quickly. In a video conferencing application, high throughput is needed to transmit video and audio data in real time without delay or interruption. However, applications that involve transmitting text-based data, such as email, instant messaging, and chat applications, don’t necessarily require high throughput.
• Availability — Availability is the ability of a system to be continuously operational for a desirably long period. High availability is measured as a percentage, with 100% meaning a service that has 0 downtimes. Most services fall between 99% and 100%. some systems are required to be available 24x7x365 some might only be during working hours? For example, for An orders platform for a stock broker, it would be a waste of resources to keep it running beyond trading hours, whereas the service of the order in e-commerce would need to be available all the time.

Depending on the domain and business requirements, there could be more dimensions to analyse, such as data scan, compliance requirements, data privacy, etc. The idea is to understand the requirements both quantitatively and qualitatively and understand the acceptable trade-offs.

For example, in a healthcare system, compliance with HIPAA regulations is critical. Any system that processes protected health information (PHI) must ensure the confidentiality, integrity, and availability of PHI. This requirement significantly influences the design of the system and may lead to additional security measures such as encryption and access control.

This analysis will help you estimate the system’s capacity or performance requirements and project the cost and budgeting requirements.

Marketing and sales teams will be using the insights generated by the system to improve their strategies.

Since the system is expected to provide insights in near real-time, the latency requirements are critical.

Let’s assume that the company wants insights to be generated within 5 seconds of a customer record being processed. This means that the system must be able to process 200,000 records per second (1 million records / 5 seconds).

In addition to the latency requirements, the system must also be able to process 1 million customer records per day. This means that the system must be able to process 11.6 customer records per second (1 million records / 86,400 seconds in a day).

Since the retail company operates 24x7x365, the data processing system must also be available at all times. This means that the system should have high availability, with minimal downtime for maintenance or upgrades.

Other considerations: The system should also be designed to handle large amounts of data, with built-in redundancy and fault tolerance to prevent data loss or system failure. Additionally, the system must comply with data privacy regulations, such as GDPR and CCPA, to ensure the protection of customer data.

Calculations:

• Latency: To meet the 5-second latency requirement, the system must be able to process 200,000 records per second. This means that each record should take no more than 5 microseconds to process (5 seconds / 1 million records). If the system takes longer than 5 microseconds per record, the latency requirements will not be met.
• Throughput: To process 1 million records per day, the system must be able to process 11.6 records per second. This means that each record should take no more than 86.4 milliseconds to process (86,400 seconds in a day / 1 million records). If the system takes longer than 86.4 milliseconds per record, the throughput requirements will not be met.

By analysing the problem statement and identifying the key requirements and constraints, we can now make design decisions that will meet the needs of the stakeholders and ensure the success of the system.