paint-brush
The Core Principle of Separation of Concerns & Twitter's Value-Driven Approachby@pchandel09
700 reads
700 reads

The Core Principle of Separation of Concerns & Twitter's Value-Driven Approach

by Puneet ChandelJuly 20th, 2023
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Achieving scalability and robustness in system design requires careful consideration of business requirements, architectural principles, and a deep understanding of technology One key principle that significantly contributes to building a scalable architecture is the Separation of Concerns (SoC). This principle is crucial for modularized systems, enabling evolving architectures and faster value delivery.
featured image - The Core Principle of Separation of Concerns & Twitter's Value-Driven Approach
Puneet Chandel HackerNoon profile picture


In today's rapidly advancing world, it is imperative to embrace the latest technologies in order to craft systems that are scalable, reliable, maintainable, and portable. However, this approach often leads to reactive designs that are not adaptable to evolving needs. System design should be driven by requirements, not by technology.  Achieving a successful system design calls for a profound understanding of both architecture and business requirements, ensuring that the resulting solution aligns seamlessly with the intended goals.


For instance, when designing a system to handle 10 million daily requests with 20 ms latency, it's tempting to opt forMicroservices architecture, database sharding, and highly distributed cloud infrastructure. While these choices may work, they often overlook the importance of employing architectural design principles.


A prime example of this system is "Stack Overflow," which is built on a monolithic architecture. Its success stems from a profound technical understanding and the utilization of software architecture principles.


The key point here is that fundamental design choices determine the system's trajectory.


Architects gravitate towards the latest technologies or attempt to implement a multitude of design principles to achieve scalability. Like patterns:  DDD, EDA, Microservices, serverless, CQRS, layered architecture, and design principles: SOLID, Principle Of Least Astonishment, DRY, Explicit dependency, etc


While architects aspire to implement these principles, in reality, architects are often constrained by time, resources, and urgency, and the evolving business and technology landscape may not always provide an opportunity to rebuild and implement the best architecture choices.


This is why it is crucial to design systems based on fundamental design principles.


Separation of Concerns

This article highlights the importance of one of the core architectural principles that establish the very foundation for achieving success and facilitate the implementation of other architectural principles.


The principle states that a system should be built on top of manageable components, with each component addressing a specific concern while minimizing overlap.

A successful SoC implementation requires clearly defined component responsibilities, clearly bounded contexts, well-defined interfaces, loose coupling, and high cohesion.


Enablers for SoC include SOLID Principles, Message Queues, Event Bridges, state management constraints, API gateway, and Streaming platforms.


SoC is THE most important architectural principle as it allows your architecture to evolve over time to support both technology and business vision.


Some major advantages of this architecture include:


  • Promotes Modularity

  • Reduce blast radius

  • Enable Faster time to market

  • Enhances  Maintainability, Scalability, and durability

  • Improves Data Quality

  • Enable evolving architecture and modernization like Cloud Migration, Containerization, Event streaming, etc.


This principle is applicable to any system, whether it's legacy or modern: Monolith, Microservices, SOA, Enterprise IT, SaaS applications, traditional web applications, backend engines, or analytics platforms.


Consider SoC as the foundational design pattern for any system. A system lacking SoC will have poor extensibility and hinder future architectural evolution


How Twitter Monetization offering embodies this principle

The architecture of Twitter is built upon several components, each with clearly defined capabilities and boundaries. It serves as a good reference for large-scale systems built using the principle of Separation of Concerns, coupled with high-performance infrastructure to support high throughput, availability, and low latency, as demonstrated by their "Manhattan" infrastructure.


Some major components and Services include:


  • Timeline Mixer

  • Ad Mixer

  • Onboarding Service

  • People discovery

  • Prediction service

  • Recommendation and Analytics Engine

  • Search Service

  • Indexing and MapReduce

  • And some technology choice that enables scalability

    • Storage - Hadoop, Manhattan, Vertica, flockDB
    • Cache  - Redis and Memcache
    • Events Processing - Kafka, TimeSeries Aggregator (TSAR)


For deep dive into Twitter’s infrastructure please refer to:

The infrastructure behind Twitter's scale

Processing-billions-of-events

Manhattan

So how does the principle of Separation of Concerns benefit Twitter?

  1. Application modernization: Retire Timeline Mixer with a more advanced Home Mixer service.
  2. Deliver value sooner: Twitter subscription service for content creator

Let’s understand how Twitter might have delivered this service faster using the SoC architecture principle.


High-level Requirements

The requirement has the following broad features


Capability: Offer Monetization for content creators

Features:

  • Content creators : Enable monetization, receive payments, send exclusive tweets, view exclusive tweets on user timelines
  • Subscriber: Subscribe to a creator, Make payment, View exclusive posts on home timeline
  • Payment gateway: Collect payment methods and process payment


High-Level architecture: The architecture below demonstrates how these components are orchestrated to build the desired capability.





Build & Development


  1. Based on existing Twitter architecture, following major services might have been modified
  • Timeline Mixer
    • Author timeline - view exclusive tweets in a separate section
    • User home timeline - view exclusive tweets in a separate tab
  • Publisher Service
    • Persist and cache exclusive tweets
  • Graph service
    • Fetch subscription information for building follower graph
  • Security and access control
    • Control who can view/retweet a post


  1. Major components to build:
  • Payment gateway: For this phase, Twitter used Stripe but maybe in the future Twitter will build its own Payment gateway service
  • Subscription service:
    • Enable Monetization
    • Persist subscription information
  • Integrations to existing services and data store


How did this architecture benefit Twitter?

  1. Time to Value

    1. Build components independently without impacting existing stack

    2. Separate teams can build/test each components for faster build

    3. New component can be build on pilot infrastructure and scaled independently based on adoption


  2. Reduce blast radius

    1. By separating concerns into distinct modules or components, failures or errors within one module are contained and do not affect other modules.

    2. Isolation limits the blast radius and prevents widespread system failures.


  3. Enable evolvability

    1. The architecture allows for evolution over time to accommodate changing requirements. For example, the payment gateway can be replaced with a custom-built gateway without impacting the overall stack.
    2. Future services can be integrated or built to further enhance capabilities.



In conclusion, this article emphasizes the significance of building software systems based on fundamental design principles, with Separation of Concerns being the most critical principle. The example of Twitter showcases how applying this principle contributes to successful system design, enabling scalability, maintainability, and adaptability to evolving business and technological landscapes.


What's not covered in the article?

  • Twitter Specific technology stack: Manhattan, Gizmoduck, Apache storm, Lucene, Redis, graphql, etc.
  • Detail on various Twitter services mentioned above
  • Architecture styles: Domain-driven design, Microservices pattern, Event-driven architecture, CQRS, etc


Please feel free to reach out if you have any questions!