System Design and Layered Architectures Flashcards
Microservices
It’s a small, independent, and self-contained unit of functionality inside of a larger application. They communicate via RESTful API’s.
An example microservice is an order download feature on an order website.
Function as a service (FaaS)
This is a small, self-contained piece of code that does a very specific task. Can be triggered by an event. It can also be run by the cloud. Scaling can be automatic. Only pay for the compute time your functions use.
FaaS can be built out into microservices.
Stateless
When a service doesn’t have or use any information from previous interactions.
Example: Azure cloud services, HTTP
Stateful
When a service does have or use any information from previous interactions.
Example: data storage, online banking
Monolithic Architecture
This is when one code base performs multiple business functions. Components are tightly coupled and interdependent. The application is deployed as a single unit.
Example: WeChat
Service-oriented Architecture (SOA)
This is when applications are assembled as a collection of loosely coupled components that provided services to each other. Services can be used in different applications. They can communicate with each other regardless of the underlying platform or technology. They have clear and standardised interfaces, and can be self-contained and deployed and managed independently.
Example: e-commerce, travel cooking systems, healthcare systems
Event-driven Architecture
This is when applications communicate by producing and consuming events. An event is a change in state, or an update, like an item being put in a shopping cart on an e-commerce website.
Event Producers: Applications that generate events, such as a shopping cart.
Event Consumers: Applications that subscribe to events and react to them, such as a recommendation system reacting to an item added to a cart.
Event Router/Broker: this routes events from producers to consumers, such as a messaging queue or a more complicated event mesh.
Layered Architecture
This is when applications are organised into a hierarchy of layers. Each layer handles a distinct part of the application’s functionality, hides complexity of lower layers, and are in a top-down fashion.
Here are some common layers:
1. User Interface (UI) (i.e. shopping cart)
2. Application Layer (Business Logic) (i.e. order processing)
3. Data Access Layer (i.e. DB for orders)
4. Infrastructure Layer (i.e. logging, security, and support services)
SOLID Principles
These are five design principles to make object-oriented programming more readable, flexible, and maintainable.
Single Responsibility Principle
There should never be more than one reason for a class to change. Each class should only have one responsibility.
This makes classes easier to understand and modify, write unit tests with more focus, and reduces the impact of changing the class responsibility.
Open-closed Principle
Software entities should be open for extension, but closed for modification.
Extension: adding new features without modifying existing code. This includes overriding existing functions.
Modification: changing existing function.
This reduces the risks of bugs when making changes, and adapts to changing requirements better.
Liskov Substitution Principle
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
This ensures polymorphic behaviour, that subclasses adhere to superclass parameters, and that replacing a superclass object with a subclass object won’t break the programme.
Interface Segregation Principle
Clients shouldn’t be forced to depend upon interfaces that they don’t use.
This decouples classes, making the code more modular and maintainable, allows for more flexible implementations of interfaces, and avoid unnecessary dependencies.
Dependency Inversion Principle
Depend upon abstractions, not concretes.
This results in loose coupling, more flexibility, and better maintainability.
High-level modules shouldn’t import anything from low-level modules. The two should depend on abstractions, such as interfaces.
ACID Properties
These are four properties for SQL databases that help preserve data validity despite power failures, error, and other accidents.
Atomicity (ACID)
Each transaction, often composed of multiple statements, are treated as single units, which fail or succeed completely.
Consistency (ACID)
A transaction can only bring the database from one consistent state to another. Any data written to the database must be valid according to the rules. This prevents the database from corruption by an illegal transaction.
Isolation (ACID)
Each transaction is executed concurrently. This ensures that such an execution leaves the database in the same state it would’ve been had it been executed sequentially.
Durability (ACID)
Once a transaction is committed, it’ll remain committed even in the case of a system failure.
CAP Theorem
Any distributed data store can only guarantee two of the three principles:
Consistency: every read receives the most recent write or an error.
Availability: every request from a non-failing node in the system must lead to a response.
Partition Tolerance: the system continues to function despite an arbitrary number of messages being dropped/delayed by the network between nodes.
BASE Principles
NoSQL databases have the following properties.
Basic Availability: the system operates even with some node failures.
Soft State: data may not be immediately consistent across all nodes.
Eventual Consistency: data will eventually become consistent across all nodes.
RESTful API
It’s an application programming interface (API) that uses HTTP requests to get data and that adheres to the REST (Representational State Transfer) architectural style, which have the following principles.
- Client-Server Architecture: the client (application requesting data) and the server (application providing data) are separate entities.
- Statelessness: each request from the client to the server must have all relevant information to process the request, as the server doesn’t store any information about previous requests.
- Cacheability: responses from the server can be cached by the client to improve performance.
- Uniform Interface: the API has a consistent way for clients to interact with the resources.
- Layered System: the API can be built with multiple layers of servers, such as load balancers and proxies, that don’t affect client interaction with the API.
GraphQL
This is a query language and runtime for API’s that has a more efficient and flexible way for clients to interact with data as opposed to RESTful API’s. Here are some key concepts.
- Schema: a core component defining the structure and types of data available in the API. It’s the contract between the client and the API.
- Queries: used to request data from the server.
- Mutations: used to change data on the server.
- Resolvers: functions on the server that retrieve the data for each field in the schema.
Data Access Object (DAO)
It has commands and logic for accessing and interacting with the database. It separates two parts of an application that don’t need to know about each other. Make adjust to business logic changes easier.
