System Design Flashcards
Fault Isolation
Fault isolation refers to the ability to contain failures within a specific service or component without affecting other parts of the system.
Microservice
A microservice is an architectural style where an application is divided into smaller, independent services that perform specific functions. Each service operates autonomously, has its own codebase, dependencies, and can be deployed and scaled independently from other services. These services typically communicate via APIs or messaging protocols.
Monolith
A monolith is a single, unified application where all components (such as UI, business logic, and database access) are tightly integrated and run as a single unit or process. All modules share the same codebase, dependencies, and deployment cycle.
Decomposition
The verb for transition a monolith to a microservice
Microservices ecosystem
a platform of services each encapsulating a business capability. A business capability represents what a business does in a particular domain to fulfill its objectives and responsibilities. Each microservice expose an API that developers can discover and use in a self-serve manner
Service Mesh
a dedicated infrastructure layer to run fast, reliable and secure network of microservices,
container orchestration systems
Tools or platforms designed to automate the deployment, management, scaling, and networking of containers in large-scale, distributed environments. These systems manage clusters of containers, ensuring that applications run smoothly by handling tasks like load balancing, failover, scaling, and container lifecycle management.
Examples include:
Kubernetes
Docker Swarm
Apache Mesos
Describe the best way to decompose a monolith
Begin with edge cases that are already fairly decoupled from the monolith, that don’t require many changes to client facing applications, that are in use but perhaps don’t need the store.
The goal is building out minimum infrastructure needed to deliver independently deployable secure services that expose self-serve APIs.
Examples are :
- Authentication Service
- Logging and Monitoring
- Email and Notification Service
- File Upload and Storage Service
- Feature Toggle Service
How should data flow ideally during decomposition?
The data should ideally flow from the monolith to the service. However, if a service is dependent on the monolith for anything, it is recommended to create an “anti-corruption layer” ( ACL ) to make sure that the monolith concepts do not leak out. This layer normalizes data, performs API translation , and keeps clean well-abstracted versions of the monolith available.
Decouple Capability and not Code
Often by default the service extraction or monolith decomposition is imagined as a case of reusing the existing implementation as-is and extracting it into a separate service. Partly because we have a cognitive bias towards the code we design and write. The labor of building, no matter how painful the process or imperfect the result, make us grow love for it. This is in fact known as the IKEA Effect.
Rather we should be rewriting new code to decompose the logic as its own service. A rewrite also offers the ability to use a new language, or tech stack better suited for that capability.
How far should one decompose? As in how micro should we define microservices?
Go macro, then micro. We don’t want the app to be distributed system that is hard to debug, broken across transactional boundaries and hence difficult to keep consistent, or too complex for the operational maturity of the organization.
Start with larger services around a logical domain concept, and break the service down into multiple services when the teams are operationally ready.
For example, on the journey decoupling the retail system, developers may start with one service ‘buy’ that encapsulates both the content of a ‘shopping bag’ as well as capability of buying the shopping bag, i.e ‘check out’. As their ability to form smaller teams and release larger number of services grows then they can decouple ‘shopping bag’ from ‘check out’ into a separate service.
Describe Migrating ( Decomposing ) in Atomic Evolutionary Steps
- decouple the new service
- redirect users to the new service
- retire the the old code path in the monolith
Not fulfilling this entire atomic evolutionary step will otherwise increase the entropy of the company and it’s goals.
Service Orientated Architecture ( SOA )
Service-Oriented Architecture (SOA) is a design paradigm in software architecture where applications are built by composing independent services. Each service in SOA performs a specific business function and communicates with other services over a network using standardized protocols. The key principles of SOA are loose coupling, reusability, interoperability, and scalability.
