Which Of The Following Does Not Relate To System Design

Introduction

System design is the disciplined process of defining the architecture, components, modules, interfaces, and data for a complex system to satisfy specified requirements. Whether you are building a web application, an embedded device, or an enterprise‑level information system, the decisions you make during system design profoundly affect performance, scalability, maintainability, and cost. Still, not every activity or concept encountered in a development project belongs to system design. Understanding what does not relate to system design helps teams stay focused, avoid scope creep, and allocate resources efficiently. This article explores common misconceptions and clearly identifies the elements that fall outside the scope of system design, illustrating each point with practical examples and expert insights.

What System Design Actually Covers

Before isolating the unrelated items, it is useful to recap the core domains that do belong to system design:

1. Architecture Definition – Choosing between monolithic, microservices, serverless, or layered architectures; deciding on communication patterns (REST, gRPC, message queues) and data storage strategies (SQL vs. NoSQL).
2. Component Decomposition – Breaking down the system into services, modules, or classes, and defining responsibilities and boundaries.
3. Interface Specification – Designing API contracts, data schemas, and interaction protocols between components.
4. Scalability & Performance Planning – Estimating load, selecting load‑balancing strategies, caching layers, and replication mechanisms.
5. Reliability & Fault Tolerance – Incorporating redundancy, graceful degradation, circuit breakers, and disaster‑recovery procedures.
6. Security Architecture – Defining authentication, authorization, encryption, and threat‑modeling at the system level.
7. Deployment & Operations Considerations – Mapping components to environments, container orchestration, CI/CD pipelines, and observability (logging, tracing, metrics).

Anything that does not directly influence these structural or strategic decisions can be considered outside the realm of system design.

Items That Do Not Relate to System Design

Below is a curated list of activities, concepts, or topics that are frequently mistaken for system design but actually belong to other disciplines such as implementation, project management, or user experience design.

1. User Interface (UI) Layout and Visual Styling

• Why it’s not system design: UI design focuses on the look and feel of the application—colors, typography, button placement, and visual hierarchy. While UI decisions must respect the underlying system constraints (e.g., response time, data availability), the creation of mockups, style guides, or pixel‑perfect screens is the domain of UI/UX design, not system architecture.
• Typical confusion: Teams sometimes ask system architects to “design the dashboard layout.” The architect should instead provide data availability, latency expectations, and interaction contracts; the UI designer translates those constraints into visual elements.

2. Algorithmic Implementation Details

• Why it’s not system design: Choosing a specific sorting algorithm (quick‑sort vs. merge‑sort) or implementing a particular data structure (hash table vs. balanced tree) is an implementation‑level concern. System design may dictate that a component must support fast look‑ups or ordered traversal, but the exact algorithmic choice is left to developers during coding.
• Example: In a recommendation engine, the system design will specify that a “real‑time ranking service” must return results within 100 ms, but the decision to use a cosine similarity calculation versus a neural‑network based scorer belongs to the implementation phase.

3. Project Scheduling and Resource Allocation

• Why it’s not system design: Determining when a feature will be delivered, assigning developers to tasks, and managing budgets are core responsibilities of project management. System design provides a blueprint; it does not dictate sprint lengths, Gantt charts, or team composition.
• Pitfall: Over‑loading the architecture team with timeline estimations can dilute focus and lead to rushed designs that ignore critical trade‑offs.

4. Code Formatting and Style Guidelines

• Why it’s not system design: Enforcing line length, brace placement, or naming conventions falls under coding standards and is typically governed by a style guide or linting tool. These guidelines ensure readability and maintainability but have no impact on the high‑level structural decisions made during system design.
• Clarification: A well‑designed system can still be implemented with inconsistent code style; conversely, perfectly styled code does not guarantee a sound architecture.

5. Database Query Optimization (SQL Tuning)

• Why it’s not system design: While system design decides which database technology to use and how data will be partitioned, the fine‑grained tuning of individual SQL statements—adding indexes, rewriting joins, or adjusting query plans—is an operational/DBA activity.
• Relation vs. Scope: The architect may suggest “sharding by user ID” to improve scalability, but the DBA will later create the specific index strategy for each shard.

6. Content Writing and Copyediting

• Why it’s not system design: Crafting marketing copy, help‑center articles, or error‑message wording belongs to content strategy and technical writing. System design may define where messages appear (e.g., in a notification service) but does not dictate the actual textual content.
• Real‑world scenario: A notification service design includes a payload schema with a “message” field; the copywriters decide what the message says.

7. Hardware Procurement and Vendor Negotiation

• Why it’s not system design: Selecting specific server models, negotiating contracts with cloud providers, or managing inventory are operations and procurement tasks. System design may specify required compute, storage, and network characteristics, but the act of purchasing the hardware is a separate function.
• Impact: Misunderstanding this boundary can cause architects to over‑promise performance based on ideal hardware that has not yet been secured.

8. Testing Framework Selection (Unit vs. Integration)

• Why it’s not system design: Choosing JUnit, pytest, or Cypress is a testing strategy decision. While system design should ensure testability—e.g., by defining clear interfaces—it does not prescribe the exact testing tools or the proportion of unit versus integration tests.
• Best practice: Architects provide “testability criteria” (e.g., components must expose health endpoints) and let QA engineers decide on frameworks.

9. Legal Compliance Documentation (GDPR, HIPAA)

• Why it’s not system design: Drafting privacy policies, consent forms, and audit logs is part of regulatory compliance and legal work. System design must consider compliance constraints (data residency, encryption at rest) but does not produce the legal documents themselves.
• Example: An architect may require that personal data be stored in EU‑based data centers; the legal team then ensures that contracts reflect GDPR obligations.

10. Marketing Campaign Planning

• Why it’s not system design: Defining target audiences, ad spend, and channel mix is a marketing activity. System design may need to expose APIs for campaign tracking, yet the strategic planning of the campaign lies outside the architectural scope.
• Result of confusion: If marketers request “design the funnel” from architects, the team may waste time on business‑process modeling rather than on technical architecture.

How to Keep System Design Focused

Identifying non‑design elements is only half the battle; teams must also establish processes that prevent scope creep. Below are practical steps to maintain a clear boundary.

Establish a Design Charter

• Define deliverables (architecture diagrams, interface contracts, scalability assumptions).
• List excluded items explicitly (UI mockups, code style guidelines, procurement).
• Assign ownership for each deliverable to avoid ambiguity.

Use RACI Matrices

A RACI (Responsible, Accountable, Consulted, Informed) matrix clarifies who handles what. For system design:

This changes depending on context. Keep that in mind.

Conduct Design Review Gates

Before moving from design to implementation, hold a design review that checks for:

• Alignment with functional requirements.
• Absence of non‑design items (e.g., UI specifics).
• Clear hand‑off points for downstream teams (QA, Ops, Content).

If any out‑of‑scope items appear, assign them to the appropriate owners and document the decision.

Document Assumptions and Constraints Separately

• Assumptions (e.g., “average request size ≤ 2 KB”) belong in the design doc.
• Constraints (e.g., “must comply with PCI DSS”) are noted, but the implementation of specific controls (encryption keys, audit logs) is delegated to security engineers.

Frequently Asked Questions

Q1: Can system design ever include UI decisions?

A: Only at a high level. System design may dictate that the front‑end must support asynchronous updates or offline mode, but detailed pixel‑perfect layouts are strictly UI/UX territory Nothing fancy..

Q2: What if a design decision directly impacts cost, such as choosing a particular cloud service?

A: Cost considerations are part of architectural trade‑offs and thus belong to system design. That said, the actual procurement process—negotiating discounts, signing contracts—remains an operations task The details matter here..

Q3: Is performance testing part of system design?

A: Defining performance targets (e.g., 99th‑percentile latency ≤ 200 ms) is a design activity. Executing load tests, analyzing results, and tuning the system are testing/operations activities Small thing, real impact..

Q4: How do we handle “security requirements” that seem like legal documents?

A: System design should capture technical security requirements (encryption, access control) derived from legal mandates. Drafting the legal language and compliance evidence is a separate legal/compliance function.

Q5: Can a system architect also act as a project manager?

A: While it’s possible in small teams, mixing roles often blurs boundaries, leading to design decisions being driven by schedule pressure rather than technical merit. Keeping the roles distinct preserves design integrity.

Conclusion

System design is the blueprint that guides how a complex solution will be built, scaled, and maintained. Still, Distinguishing what does not relate to system design—such as UI styling, algorithmic coding details, project scheduling, code formatting, query tuning, content writing, hardware procurement, testing framework selection, legal documentation, and marketing planning—helps teams stay focused, reduces miscommunication, and ensures that each discipline contributes its expertise where it matters most. By establishing clear charters, RACI matrices, and design‑review gates, organizations can safeguard the architectural vision while allowing specialized teams to excel in their respective domains. The result is a solid, well‑engineered system that meets both technical and business objectives without unnecessary friction or wasted effort Took long enough..