A Primer for System Design

My friends and I often challenge ourselves in building Low-Medium complex systems to see how they perform when shared with an end-customer. The feedback is captured; which is then dissected for abnormalities.

Recently, I asked ChatGPT to build an algorithm and it generated a code which was awesome. However, system design is not just about that. It is about determining in building, designing a robust collection of architectural components that can scale (both vertically and horizontally), is fault tolerant and can even run in a fail-safe mode, among other things. Today, complex systems and applications can even run in mines/remote locations across the globe – where there is zero network!

The whole process of system design is an extensive topic, that requires experience, expertise, knowledge of software, languages, technology trends and various other factors to build a large enterprise system. All these put together universal concepts, best practice guidance, and emerging ideas are how one can adapt in building a successful enterprise System. It is very important to also understand the important tradeoffs (say microservices vs SOA or selection of tools/ Languages/Infra restrictions etc), addressing cross cutting concerns viz. anything that affects throughout the system such as Security, Logging, fault tolerance etc. For instance, to build a printing library, one need not write thousands of lines of code in Java vs an interoperable library that can be built on C# with one-third the lines of code.

A system can be classified into at-least three major building blocks:

1. At the heart of the framework likes well-defined business requirements, surrounded by many entities such as
2. Architectural Vision /Framework components, Governance etc. and
3. Real-time business users

These three archetypes should always be tightly woven. System design calls for multiple stakeholders viz. Business Architect, Application Architect(s), Data Architect, Technology Specialist, Infrastructure experts, and various others to work in tandem. Keeping the program sponsor updated on the progress (including the tools, technologies) at every stage is important. Checks should also be kept on the cost overruns.

The very fundamental blocks of system should be broken into business components. Understanding the architectural and business landscape along with ease of injection of various components, building the computing components repository such as servers, databases, messages, queues, logging, caching, application, load balancers and understanding its interactions to a good extent is highly recommended

Selection of tools (from the above section) plays a vital role in deciding the future course of the application/product. Identifying interfaces and modus operandi of touch points for third party integrations should be carefully thought through for Electronic Data Exchanges

Understanding the tradeoffs during selection of each artifact vs technology should be a key step to a good robust system design. For e.g. today, a high volume data handling can be served by Teradata vs Oracle or TimesTen DB, but one needs to identify the trade off’s while selecting these tools coupled with the business asks. There are plenty of other factors such as licensing costs, support model, type of DB (on Prem vs cloud) etc.; but it is with evolution and newer inventions, time is the only factor that will make the design last long. Couple of decades back, the commonly used shopping cart was less scalable, untenable, poor transaction handling, limited infrastructure is now a past thing. Today, it has become a robust, multi-tiered architecture, high in integrations, built on extremely durable infra and can seemingly capture a step-by-step transaction via blockchain and with AI embedded programs, thus delivering a seamless journey for the end-user.

Building these architectural blocks and making them perform to scale should be the goal; with this comes the evolution of UML which would encompass the enterprise to Functional and Technical components keeping the model in mind. As an instance, Object Relation mapping technologies have undergone a sea change starting with Toplink àJDOs à EJB à Hibernate. Although the core concept of these tools is the same, it is important to keep the architectural framework components current and up-to-date even if it involves a technology reconsideration. Not doing so may later lead to lack of support, deprecated methods, redundant license costs. Thus, the framework must be flexible for a technical overhaul if required.

A step further in the application architecture, below are some basic pillars –

1. A strong recommendation for OOP Applications is having a foundation of the Five SOLID Principles which defines the rules and best practices of designing large scale applications. These help us understand the usage of absolute design patterns, usage of anti-patterns which every engineer should learn, help refactor to keep it clean, extendable, and testable.
2. API first design approach – These are the first building blocks of platform, and everything that revolves around this will be consumed by various endpoints. This set produces a set of modular, interoperable APIs when combined would achieve a certain set of functionalities. This reusable API approach involves methods and functions that are consistent and reusable. Largely the contract should be established which involves a good design (data), proper planning and collaboration. After the model is frozen, development teams can work in parallel on multiple APIs and eventually reducing time to market. A proper governance must be established and enforced to have desired outcomes.
3. Building smart and scalable wireframes – During application design, building a modern robust wireframe is often neglected. It is very important to comply with modern wireframes that share heatmap results based on number of clicks, navigation traces and its efficiency via simulations. Again, these must be run with the stakeholder as there could be a bearing to the technical design.

While time may be the real test to check the behavior and draw patterns out of it, it is equally important first to have an enterprise design that is scalable between layers. Providing assumptions and signoffs will prove to be an equally decisive factor at later stages. Having all data points with respect to Scalability, Performance, Secure, Consistent usage of design patterns, CAP theorems, communication mechanism etc., will have equal bearing to the entire testament of the design.

Start simple yet keep it scalable.