Key concepts of System design 3: System Context
This is the last conceptual piece before designing the actual application and dig into more technical aspects.
In this chapter, we explore the "System Context" by dividing it into two main sections: Business Context and Technical Context. Each section provides a comprehensive checklist to ensure a thorough understanding of the environment in which the system operates. We emphasize components and their roles in both contexts to create a holistic overview of the system's environment.
Where are we…
In the previous chapters, we laid the foundation for designing our system—a real-time communication platform inspired by Discord. Our journey began with identifying the key problem, then moved into detailing requirements, and concluded with an analysis of constraints. Here's a brief summary of the preceding chapters:
Chapter 1: Define the Problem
We clarified what we aim to build: a real-time communication platform with features like text, voice, and video communication. We emphasized scalability, reliability, and a community-driven design.
Chapter 2: Gather and Prioritize Requirements
We identified core functional requirements, such as real-time messaging and multi-chat channels, and critical non-functional requirements like 99.99% availability and sub-100ms message delivery latency.
We also outlined stakeholders and their roles, from end users to developers and business owners.
Chapter 3: Analyze Constraints
We explored technical and business constraints, including deployment choices (cloud vs. on-premise), team expertise, budget limitations, and time-to-market considerations. We identified our project as a greenfield effort, providing us flexibility in many design decisions.
Building on these foundational chapters, this section will delve into the System Context, focusing on how components are interpreted and interact within both the Business and Technical domains.
Business Context
The Business Context defines how the system aligns with the organization's objectives, stakeholders, and market dynamics. Components in this context are viewed as business entities or roles, emphasizing their value to the organization and users.
Key Components and Their Roles
Platform Users:
Role: Core consumers of the system, including individual users, businesses, and community groups.
Value: Drive adoption and revenue, provide feedback for continuous improvement.
Business Owners and Investors:
Role: Decision-makers who define goals, allocate budgets, and evaluate ROI.
Value: Ensure the system meets strategic objectives and financial viability.
Customer Support Teams:
Role: Handle user queries, issues, and feedback.
Value: Enhance user satisfaction and retention.
Regulatory Bodies:
Role: Ensure compliance with laws and regulations like GDPR, HIPAA, etc.
Value: Mitigate legal risks and establish trust with users.
Competitors and Market Forces:
Role: External entities that shape the competitive landscape.
Value: Influence strategic differentiation and feature prioritization.
Business Considerations
Revenue Models: Subscription plans, freemium tiers, and ad-based monetization strategies.
Stakeholder Communication: Regular updates to ensure alignment with goals.
Risk Mitigation: Addressing market competition, regulatory changes, and user churn.
Here an example of business concept, roughly based on the use cases whe describe in chapter 1.
Technical Context
The Technical Context outlines the system's operational and integration environment. Components here are interpreted as technical entities, focusing on their implementation, scalability, and maintainability.
Key Components and Their Roles
Client Applications:
Role: Interfaces for end users (e.g., web, mobile, and desktop clients).
Implementation: Built using frameworks like React or Flutter for responsive and seamless UX.
Backend Services:
Role: Handle core functionalities like real-time messaging, user authentication, and data persistence.
Implementation: Deployed as microservices, using languages like Node.js or Go.
Database Systems:
Role: Store structured and unstructured data (e.g., chat history, user profiles).
Implementation: Utilize relational (e.g., PostgreSQL) and non-relational databases (e.g., MongoDB).
APIs and Integrations:
Role: Facilitate communication between components and with external systems.
Implementation: RESTful and GraphQL APIs with secure endpoints.
Infrastructure:
Role: Support deployment, scaling, and monitoring of the system.
Implementation: Hosted on cloud platforms like AWS or Azure, leveraging container orchestration (e.g., Kubernetes).
Technical Considerations
Scalability: Designing for millions of concurrent users.
Security: Employing encryption, authentication, and intrusion detection.
Performance Metrics: Ensuring sub-100ms latency for real-time interactions.
The technical context it is used to identify the main components and protocols.
No precise decision about products, framework or technology implementation, but this one is where the structure of the application is defined.
By thoroughly analyzing both the business and technical contexts, we create a robust foundation for informed system design decisions. Each of these considerations will be revisited and refined as the design process evolves.
This step can seem useless but it is crucial before designing the actual system.
In the next chapter we will start designing the actual system and identifying internal component in detail as well as service that we can use in order to implement all the functional and non functional requirements we defined.
Articles I enjoyed this week
Coding Challenge #81 - Brainf*ck Interpreter the latest chapter of the popular series created by John Crickett