Show Menu
Cheatography
  1. Home >
  2. Programming >

Architectural Concepts 1 Cheat Sheet (DRAFT) by

Cheatsheet about Architectural Concepts asked during interview.

This is a draft cheat sheet. It is a work in progress and is not finished yet.

SOLID Principles

Single Respon­sib­ility Principle (SRP): A class should have only one reason to change, meaning it should have a single respon­sib­ility or concern.
Open-C­losed Principle (OCP): Software entities (classes, modules, functions) should be open for extension but closed for modifi­cation. This means that you should be able to add new functi­onality without modifying existing code.
Liskov Substi­tution Principle (LSP): Subtypes must be substi­tutable for their base types without altering the correc­tness of the program. In other words, derived classes should be able to be used in place of their base classes without causing issues.
Interface Segreg­ation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. Instead of having a single large interface, it is better to have smaller and more specific interf­aces.
Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstra­ctions. Abstra­ctions should not depend on details; details should depend on abstra­ctions. This principle promotes loose coupling and allows for easier modifi­cation and testing.

Creational Patterns

Singleton: Ensures only one instance of a class is created and provides a global point of access to it.
Factory Method: Defines an interface for creating objects but allows subclasses to decide which class to instan­tiate.
Abstract Factory: Provides an interface for creating families of related or dependent objects without specifying their concrete classes.
Builder: Separates the constr­uction of complex objects from their repres­ent­ation, allowing the same constr­uction process to create different repres­ent­ations.
Prototype: Creates new objects by cloning existing ones, avoiding the need for complex initia­liz­ation.
 

Why MICROS­ERV­ICES?

Scalab­ility: Each micros­ervice can be deployed and scaled indivi­dually, enabling better resource utiliz­ation and handling varying levels of load
Flexib­ility and Agility: using different techno­logies and progra­mming languages if needed for different services. Faster develo­pment and deployment cycles
Fault Isolation and Resili­ence: Failures are isolated to individual services. Resiliency can be implem­ented by redund­ancy, fallback mechan­isms, and graceful degrad­ation
Continuous Delivery and DevOps: Each micros­ervice can have its own develo­pment, testing, and deployment pipeline, allowing for faster iterations and faster time to market.

Structural Patterns

Adapter: Converts the interface of a class into another interface that clients expect, allowing classes with incomp­atible interfaces to work together.
Decorator: Dynami­cally adds new behaviors to an object by wrapping it in a decorator object that provides additional functi­ona­lity.
Proxy: Provides a surrogate or placeh­older object that controls access to another object, adding extra functi­onality or contro­lling the object's access permis­sions.
Composite: Composes objects into tree structures to represent part-whole hierar­chies, allowing clients to treat individual objects and compos­itions uniformly.
Facade: Provides a unified interface to a set of interfaces in a subsystem, simpli­fying its usage for clients.
 

Micros­ervices Commun­ication

HTTP/REST: HTTP with RESTful APIs. Each micros­ervice exposes a set of well-d­efined endpoints.
Messag­ing­/Ev­ent­-dr­iven: Commun­icate with each other through asynch­ronous messaging using a message broker or event bus. One micros­ervice publishes events or messages, and other micros­ervices can subscribe to these events and react accord­ingly. Allows for loose coupling and enables better scalab­ility and fault tolerance.
RPC (Remote Procedure Call): RPC is a commun­ication pattern where one micros­ervice directly calls a method or service in another micros­ervice.
Service Mesh: A service mesh is a dedicated infras­tru­cture layer that handles commun­ication between micros­erv­ices. Provides features like service discovery, load balancing, and security.
API Gateway: An API gateway acts as a single entry point for client applic­ations to commun­icate with multiple micros­erv­ices. It can handle authen­tic­ation, request routing, load balancing, and protocol transl­ation. API gateways provide a unified interface for clients and help to decouple frontend applic­ations from the comple­xities of micros­ervices commun­ica­tion.

Behavioral Patterns

Observer: Defines a one-to­-many dependency between objects, so that when one object changes state, all its dependents are notified and updated automa­tic­ally.
Strategy: Defines a family of interc­han­geable algorithms and encaps­ulates each one, allowing them to be used interc­han­geably based on the context.
Command: Encaps­ulates a request as an object, allowing clients to parame­terize clients with queues, requests, and operat­ions.
Iterator: Provides a way to access elements of an aggregate object sequen­tially without exposing its underlying repres­ent­ation.
Template Method: Defines the skeleton of an algorithm in a base class, while allowing subclasses to override certain steps of the algorithm.