EP175: What is the SOLID Principle?

🚀 Faster mobile releases with automated QA (Sponsored)

Manual testing on mobiles devices is too slow and too limited. It forces teams to cut releases a week early just to test before submitting them to app stores. And without broad device coverage, issues slip through.

QA Wolf gets engineering teams to 80% automated test coverage in weeks, with tests running on real iOS devices and Android emulators—all in 100% parallel with zero flakes.

• QA cycles reduced to just 15 minutes

• Multi-device + gesture interactions are fully supported

• Reliable test execution with zero flakes

• Human-verified bug reports

Engineering teams move faster, releases stay on track, and testing happens automatically—so developers can focus on building, not debugging.

Rated 4.8/5 ⭐ on G2

---

This week’s system design refresher:

• What is the SOLID Principle?

• Common HTTP Status Codes

• ByteByteGo Technical Interview Prep Kit

• How Clean Architecture Works?

• How does Docker Work?

• How Large Language Models Work?

• Featured Jobs

• SPONSOR US

---

What is the SOLID Principle?

SOLID offers guidelines to create software that is easy to understand, modify, and extend.

The SOLID acronym stands for:

S -> Single Responsibility Principle
O -> Open/Closed Principle
L -> Liskov Substitution Principle
I -> Interface Segregation Principle
D -> Dependency Inversion Principle

• The Single Responsibility Principle (SRP) states that a class should have only one reason to change. In other words, it should have a single, well-defined responsibility or task within a software system.

• The Open/Closed Principle (OCP) states that software entities, such as classes, should be open for extension but closed for modification. This means you can add new functionality without altering existing code.

• The Liskov Substitution Principle (LSP) states that objects of a derived class should be able to replace objects of the base class without affecting the correctness of the program.

• The Interface Segregation Principle (ISP) emphasizes that classes or components that use interfaces should not be forced to depend on interfaces they don't use.

• The Dependency Inversion Principle (DIP) states that high-level modules (or classes) should not depend on low-level modules; both should depend on abstractions, such as interfaces.

Over to you: Which SOLID principle do you find most useful or challenging in your daily development work?

---

Common HTTP Status Codes

HTTP status codes are issued by a server in response to a client’s request. These concise responses from servers are super useful when debugging our web apps, mobile apps, or APIs.

• 1xx Informational: Signals client’s request received, and processing continues (e.g., 100 Continue).

• 2xx Success: Confirms request was successfully completed (e.g., 200 OK).

• 3xx Redirection: Requires client action, like following redirects (e.g., 301 Moved Permanently).

• 4xx Client Error: Indicates client-caused request failures (e.g., 404 Not Found).

• 5xx Server Error: Shows server failures in processing requests (e.g., 500 Internal Server Error).

Over to you: Which category confuses you most, and why?

---

ByteByteGo Technical Interview Prep Kit

Launching the All-in-one interview prep. We’re making all the books available on the ByteByteGo website.

What's included:

• System Design Interview

• Coding Interview Patterns

• Object-Oriented Design Interview

• How to Write a Good Resume

• Behavioral Interview (coming soon)

• Machine Learning System Design Interview

• Generative AI System Design Interview

• Mobile System Design Interview

• And more to come

---

How Clean Architecture Works?

Clean Architecture is a way of organizing software applications so that they are easy to understand, maintain, and scale. Clean Architecture has 4 layers, each with a clear role. The dependencies between these layers always point inward, ensuring a loosely coupled, testable, and maintainable system.

Let’s look at the layers:

1. Entities: These are the core rules and logic of the business. They represent the most stable part of the system and are independent of any external systems or frameworks.

2. Use Cases: These define the specific operations your application can perform. They orchestrate the flow of data between entities and external interfaces but don’t care about how the data is displayed or stored.

3. Interface Adapters: This layer includes Controllers, Presenters, and Gateways. It converts data from the outer layers (like the web, database, or UI) into a form that the use cases and entities can understand.

4. Frameworks and Drivers: These are external tools and systems like the database, web UI, or devices. They sit on the outside and depend on the inner layers.

Over to you: What else will you add to understand the working of Clean Architecture?

---

How does Docker Work?

Docker's architecture comprises three main components:

• Docker Client
  This is the interface through which users interact. It communicates with the Docker daemon.

• Docker Host
  Here, the Docker daemon listens for Docker API requests and manages various Docker objects, including images, containers, networks, and volumes.

• Docker Registry
  This is where Docker images are stored. Docker Hub, for instance, is a widely-used public registry.

---

How Large Language Models Work?

1. Data Collection and Tokenization.
   LLMs begin by ingesting massive volumes of text from sources like books, websites, and code. This text is cleaned and broken down into smaller units (tokens) to prepare it for training.
   

2. Pre-training with Transformer Architecture
   Using the transformer model and self-attention mechanisms, the system learns to predict the next token in a sequence. This process adjusts billions of parameters to develop a broad understanding of language.
   

3. Fine-Tuning for Specific Tasks
   The pretrained model is then tailored for specific applications through fine-tuning techniques, aligning its behavior with human preferences or specialized tasks. Some methods are RLHF, LoRA, and so on.
   

4. Inference and Response Generation
   The model generates responses based on input prompts at inference time by predicting the next most likely tokens. Advanced strategies and retrieval mechanisms can improve fluency and factual accuracy.
   

5. Optimization and Deployment
   Before deployment, the model is compressed and filtered to ensure speed, efficiency, and safety. It’s then deployed in environments like cloud platforms and edge devices for real-world use.

Over to you: What else will you add to this high level flow?

---

Featured Jobs

• Technical Strategist

  • Listing

  • Description: Your mission as Tenex’s Technical AI Strategist involves owning client relationships, diagnosing critical workflow bottlenecks, setting product strategy, data infrastructure, delivering strategic recommendations, and implementing products that set the stage for AI value realization.

  • Compensation is directly tied to the revenue that you and your team produce.

• Forward Deployed Engineer

  • Listing

  • Description: As a Forward Deployed AI Engineer at Tenex, you design and implement custom AI-driven solutions, partnering directly with clients to translate business challenges into scalable systems.

  • Compensation is based on output, uncapped.

---

SPONSOR US

Get your product in front of more than 1,000,000 tech professionals.

Our newsletter puts your products and services directly in front of an audience that matters - hundreds of thousands of engineering leaders and senior engineers - who have influence over significant tech decisions and big purchases.

Space Fills Up Fast - Reserve Today

Ad spots typically sell out about 4 weeks in advance. To ensure your ad reaches this influential audience, reserve your space now by emailing sponsorship@bytebytego.com.