In: Mobile App Development, Web Development

System Design, every developer in the world came through this term before developing architecture or design for software.

System design is the process of designing the elements of a system such as the architecture, modules, and components, the different interfaces of those components, and the data that goes through that system.

This process is to provide sufficient detailed data and information about the system and its system elements to enable the implementation consistent with architectural entities as defined in models and views of the system architecture.

Elements of a System

An abstract representation of elements of a system design featuring a tower made of computer circuitries in pink and blue tones.
  • Architecture – This is the conceptual model that defines the structure, behaviour, and views of a system. We can use flowcharts to represent and illustrate the architecture.
  • Modules – These are components that handle one specific task in a system. A combination of the modules makes up the system.
  • Components – This provides a particular function or group of related functions. They are made up of modules.
  • Interfaces – This is the shared boundary across which the components of the system exchange information and relate.
  • Data – This is the management of the information and data flow.

Major Tasks Performed During the System Design Process

Initialize design definition.

  1. Plan for and Identify the technologies that will compose and implement the systems elements and their physical interfaces.
  2. Determine which technologies and system elements have a risk of becoming obsolete or evolving during the operation stage of the system. Plan for their potential replacement.
  3. Document the design definition strategy, including the need for and requirements of any enabling systems, products, or services to perform the design.

Establish system design characteristics

  1. Define the design characteristics relating to the architectural characteristics and check that they are implementable.
  2. Define the interfaces that were not defined by the System Architecture process that need to be defined as the design details evolve.
  3. Define and document the design characteristics of each system element.

Assess alternatives for obtaining system design elements

  1. Assess the design options.
  2. Select the most appropriate alternatives.
  3. If the decision is made to develop the system element, the rest of the design definition process and the implementation process are used. If the decision is to buy or reuse a system element, the acquisition process may be used to obtain the system element.

Manage the design

  1. Capture and maintain the rationale for all selections among alternatives and decisions for the design, and architecture characteristics.
  2. Assess and control the evolution of the design characteristics.

Major Tasks Performed During the System Design Process

A graphical representation of futureproofing system design elements featuring a holographic globe in pink and blue tones.

Initialize design definition

  • Plan for and Identify the technologies that will compose and implement the systems elements and their physical interfaces.
  • Determine which technologies and system elements have a risk of becoming obsolete or evolving during the operation stage of the system. Plan for their potential replacement.
  • Document the design definition strategy, including the need for and requirements of any enabling systems, products, or services to perform the design.

Establish design characteristics

  • Define the design characteristics relating to the architectural characteristics and check that they are implementable.
  • Define the interfaces that were not defined by the System Architecture processor that need to be refined as the design details evolve.
  • Define and document the design characteristics of each system element.

Assess alternatives for obtaining system design elements

  • Assess the design options.
  • Select the most appropriate alternatives.
  • If the decision is made to develop the system element, the rest of the design definition process and the implementation process are used. If the decision is to buy or reuse a system element, the acquisition process may be used to obtain the system element.

Manage the design

  • Capture and maintain the rationale for all selections among alternatives and decisions for the design, and architecture characteristics.
  • Assess and control the evolution of the design characteristics.

Basic steps for designing systems

Clarify and agree on the scope of the system

User cases

  • Description of sequences of events that, taken together, lead to a system doing something useful
  • Who is going to use this system design?
  • How are they going to use it?

Constraints

  • Mainly identify traffic and data handling constraints at scale.
  • Scale of the system such as requests per second, request types, data written per second, data read per second)
  • Special system requirements such as multi-threading, read or write oriented.

High-level architecture design (Abstract design)

Sketch the important components and connections between them, but do not go into some details.

  • Application service layer (serves the requests)
  • List different services required.
  • Data Storage layer
  • e.g., Usually, a scalable system design includes a web server (load balancer), service (service partition), database (master/slave database cluster), and caching systems.

Component Design

  • Component + specific APIs required for each of them.
  • Object-oriented design for functionalities.
    • Map features to modules: One scenario for one module.
    • Consider the relationships among modules:
      • Certain functions must have a unique instance (Singletons)
      • Core objects can be made up of many other objects (composition).
      • One object is another object (inheritance)
  • Database schema design.

Understanding Bottlenecks

  • Perhaps your system needs a load balancer and many machines behind it to handle the user requests.

    * Or maybe the data is so huge that you need to distribute your database on multiple machines. What are some of the downsides that occur from doing that?
  • Is the database too slow and does it need some in-memory caching?

Scaling your abstract design

Vertical scaling

You scale by adding more power (CPU, RAM) to your existing machine.

Horizontal scaling

You scale by adding more machines to your pool of resources.

Caching

  • Load balancing helps you scale horizontally across an ever-increasing number of servers, but caching enables you to make better use of existing resources.

    Additionally, your system design allows otherwise unattainable product requirements feasible.
  • Application caching requires explicit integration in the application code itself. Usually, it will check if a value is in the cache; if not, retrieve the value from the database.
  • Database caching tends to be “free”. When you flip your database on, you are going to get some level of default configuration which will provide some degree of caching and performance. Those initial settings will be optimized for a generic use case, and by tweaking them to your system’s access patterns you can generally squeeze a great deal of performance improvement.
  • In-memory caches are most potent in terms of raw performance. This is because they store their entire set of data in memory and accesses to RAM are orders of magnitude faster than those to disk. e.g., Memcached or Redis.
  • e.g., Precalculating results (e.g., the number of visits from each referring domain for the previous day),
  • e.g., Pre-generating expensive indexes (e.g., suggested stories based on a user’s click history
    )
  • e.g., Storing copies of frequently accessed data in a faster backend (e.g., Memcached instead of PostgreSQL.

Load balancing

  • Public servers of a scalable web service are hidden behind a load balancer. This load balancer evenly distributes load (requests from your users) onto your group/cluster of application servers.
  • Types: Smart client (hard to get it perfect), Hardware load balancers ($$$ but reliable), Software load balancers (hybrid – works for most systems)

Database replication

Database replication is the frequent electronic copying of data from a database in one computer or server to a database in another so that all users share the same level of information. The result is a distributed database in which users can access data relevant to their tasks without interfering with the work of others. The implementation of database replication for the purpose of eliminating data ambiguity or inconsistency among users is known as normalization.

Database partitioning

Partitioning of relational data usually refers to decomposing your tables either row-wise (horizontally) or column-wise (vertically).

Map-Reduce

  • For sufficiently small systems you can often get away with ad-hoc queries on a SQL database, but that approach may not scale up trivially once the quantity of data stored or write-load requires sharding your database and will usually require dedicated slaves for the purpose of performing these queries (at which point, maybe you would rather use a system design for analyzing large quantities of data, rather than fighting your database).
  • Adding a map-reduce layer makes it possible to perform data and/or processing-intensive operations in a reasonable amount of time. You might use it for calculating suggested users in a social graph, or for generating analytics reports. e.g., Hadoop, and maybe Hive or HBase.

Platform Layer (Services)

  • Separating the platform and web application allows you to scale the pieces independently. If you add a new API, you can add platform servers without adding unnecessary capacity for your web application tier.
  • Adding a platform layer can be a way to reuse your infrastructure for multiple products or interfaces (a web application, an API, an iPhone app, etc.) without writing too much redundant boilerplate code for dealing with caches, databases, etc.

Web App System Design Considerations

A blue 3D isometric icon resembling a folder surrounded by various chipset parts signifying a broader system design.
  • Security (CORS)
  • Using CDN
    • A content delivery network (CDN) is a system of distributed servers (network) that deliver webpages and other Web content to a user based on the geographic locations of the user, the origin of the webpage, and a content delivery server.
    • This service is effective in speeding the delivery of content of websites with high traffic and websites that have a global reach. The closer the CDN server is to the user geographically, the faster the content will be delivered to the user.
    • CDNs also provide protection from large surges in traffic.
  • Full-Text Search
    • Using Sphinx/Lucene/Solr – which achieves fast search responses because, instead of searching the text directly, it searches an index instead.
  • Offline support/Progressive enhancement
    • Service Workers
  • Web Workers
  • Server-Side rendering
  • Asynchronous loading of assets (Lazy load items)
  • Minimizing network requests (Http2 + bundling/sprites etc.)
  • Developer productivity/Tooling
  • Accessibility
  • Internationalization
  • Responsive design
  • Browser compatibility

System design is necessary for software development as it lets us know the requirements and fills the big gap between the developers and the user. It is the single source of truth for your product experience.

Ready to Transform Your Ideas into Reality?

At Segwitz, we’re passionate about turning your visions into powerful digital solutions. Whether you’re starting a new project or need to optimize an existing system, our team of expert developers is here to help.

Get in touch with us today and let’s build something amazing together!