The Developer’s Cheat Sheet Collection - Part 1

[ System Design - Cheat Sheet ]

System design is about creating applications that can handle real-world demands.

𝐒𝐲𝐬𝐭𝐞𝐦 𝐃𝐞𝐬𝐢𝐠𝐧 𝐂𝐨𝐦𝐩𝐨𝐧𝐞𝐧𝐭𝐬
📌 𝐍𝐞𝐭𝐰𝐨𝐫𝐤𝐢𝐧𝐠
◾ DNS - Domain Name System (resolvers, nameservers, records)
◾ Load Balancers - Hardware, software, Layer 4, Layer 7
◾ CDNs - Content Delivery Networks (caching, edge servers)
◾ Proxies - Forward, reverse, transparent, anonymous
◾ VPNs - Virtual Private Networks (tunneling protocols)
◾ Firewalls - Packet filtering, stateful inspection
◾ NAT - Network Address Translation
◾ Gateways - Connect different networks
◾ Routers - Direct traffic between networks

📌 𝐒𝐭𝐨𝐫𝐚𝐠𝐞
◾ Databases - SQL, NoSQL (key-value, document, columnar, graph), NewSQL
◾ Object Storage - Amazon S3, Google Cloud Storage, Azure Blob Storage
◾ Block Storage - Network-attached storage (NAS), storage area networks (SAN)
◾ File Systems - Distributed file systems (HDFS, Ceph), Network File System (NFS)
◾ Caching - Redis, Memcached, Varnish, CDN edge caches

📌 𝐂𝐨𝐦𝐩𝐮𝐭𝐞
◾ Servers - Bare metal, virtual machines (VMs)
◾ Containers - Docker, Kubernetes, container orchestration
◾ Serverless - AWS Lambda, Azure Functions, Google Cloud Functions
◾ FaaS - Function-as-a-Service
◾ PaaS - Platform-as-a-Service

📌 𝐂𝐨𝐦𝐦𝐮𝐧𝐢𝐜𝐚𝐭𝐢𝐨𝐧
◾ APIs - REST, GraphQL, SOAP, gRPC
◾ Message Queues - RabbitMQ, Kafka, ActiveMQ, Amazon SQS
◾ WebSockets - Real-time, full-duplex communication
◾ RPC - Remote Procedure Call, XML-RPC, JSON-RPC
◾ Pub/Sub - Publish-subscribe messaging pattern
◾ Service Mesh - Istio, Linkerd

📌 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐚𝐥 𝐏𝐚𝐭𝐭𝐞𝐫𝐧𝐬
◾ Microservices - Domain-driven design (DDD), service discovery, API gateways
◾ Monolithic - Layered architecture, MVC, MVP
◾ Event-driven - Event sourcing, CQRS
◾ Serverless - FaaS, BaaS (Backend-as-a-Service)

📌 𝐒𝐜𝐚𝐥𝐚𝐛𝐢𝐥𝐢𝐭𝐲 & 𝐑𝐞𝐥𝐢𝐚𝐛𝐢𝐥𝐢𝐭𝐲
◾ Horizontal Scaling - Load balancers, auto-scaling groups
◾ Vertical Scaling - Larger instances, more resources
◾ Replication - Master-slave, master-master
◾ Sharding - Partitioning data across multiple databases
◾ Redundancy - Multiple instances, failover mechanisms
◾ Fault Tolerance - Graceful degradation, circuit breakers
◾ Disaster Recovery - Backups, replication, geo-redundancy

📌 𝐒𝐞𝐜𝐮𝐫𝐢𝐭𝐲
◾ Authentication - Multi-factor authentication (MFA), single sign-on (SSO), OAuth, OpenID Connect
◾ Authorization - Role-based access control (RBAC), Attribute-based access control (ABAC)
◾ Encryption - Symmetric, asymmetric, hashing algorithms
◾ Security Protocols - TLS/SSL, HTTPS, SSH
◾ Web Application Firewalls (WAF) - Protect against web attacks
◾ Intrusion Detection Systems (IDS) - Identify malicious activity

📌 𝐎𝐛𝐬𝐞𝐫𝐯𝐚𝐛𝐢𝐥𝐢𝐭𝐲
◾ Monitoring - Prometheus, Grafana, Datadog, New Relic
◾ Logging - ELK Stack (Elasticsearch, Logstash, Kibana), Splunk
◾ Tracing - Distributed tracing (Jaeger, Zipkin)
◾ Metrics - Counters, gauges, histograms, summaries
◾ APM - Application Performance Monitoring (Dynatrace, AppDynamics)

---

[ REST API - Cheat Sheet ]

📌 𝐂𝐨𝐫𝐞 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞𝐬
[1.] Client-Server
Separation of concerns, clients request, servers respond.
[2.] Statelessness
◾ Each request is self-contained, no server-side client context.
[3.] Cacheability
◾ Responses can be cached for improved performance.
[4.] Layered System
◾ Components are independent and can be replaced without impacting the system.
[6.] Code on Demand (Optional)
◾ Servers can extend client functionality.
[7.] Uniform Interface
◾ Standardized interaction with resources -
- Unique URIs (Uniform Resource Identifiers).
- Actions on resources are performed through representations.
- Use hyperlinks in responses to guide clients.

📌 𝐇𝐓𝐓𝐏 𝐌𝐞𝐭𝐡𝐨𝐝𝐬
[1.] GET - Retrieve a resource.
[2.] POST - Create a new resource or submit data.
[3.] PUT - Update or replace an existing resource.
[4.] PATCH - Partially modify an existing resource.
[5.] DELETE - Delete a resource.
[6.] HEAD - Similar to GET, but only retrieves headers, not the body.
[8.] OPTIONS - Get information about the communication options for a resource.

📌 𝐒𝐭𝐚𝐭𝐮𝐬 𝐂𝐨𝐝𝐞𝐬
[1.] 2xx (Success)
◾ 200 OK: Request succeeded.
◾ 201 Created: Resource created successfully.
[2.] 3xx (Redirection)
◾ 301 Moved Permanently: Resource moved to a new URI.
◾ 304 Not Modified: Resource has not changed since last request.
[3.] 4xx (Client Error)
◾ 400 Bad Request: Invalid request syntax or parameters.
◾ 401 Unauthorized: Authentication required.
◾ 403 Forbidden: Insufficient permissions.
◾ 404 Not Found: Resource not found.
[4.] 5xx (Server Error)
◾ 500 Internal Server Error: Unexpected error on the server side.
◾ 503 Service Unavailable: Server temporarily overloaded or down for maintenance.

📌 𝐑𝐞𝐬𝐨𝐮𝐫𝐜𝐞 𝐍𝐚𝐦𝐢𝐧𝐠
◾ Nouns - Use nouns for resource names => /users, /products
◾ Plurals - Prefer plural nouns for collections => /users instead of /user
◾ Hyphens - Use hyphens to improve readability => /product-categories
◾ Lowercase - Use lowercase letters for consistency.

📌 𝐁𝐞𝐬𝐭 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞𝐬
◾ Versioning
◾ Filtering
◾ Sorting
◾ Pagination
◾ Documentation
◾ Content Negotiation
◾ Idempotence
◾ Caching

📌 𝐒𝐞𝐜𝐮𝐫𝐢𝐭𝐲
◾ Authentication (OAuth 2.0,JWT (JSON Web Tokens),API Keys)
◾ Authorization (RBAC (Role-Based Access Control),ABAC (Attribute-Based Access Control))
◾ Use HTTPS
◾ Input Validation
◾ Output Encoding
◾ Rate Limiting and Throttling
◾ CORS (Cross-Origin Resource Sharing)
◾ Security Headers
◾ Security Monitoring

---

[ Test-Driven Development (TDD) Cheat Sheet ]

📌 𝐂𝐨𝐫𝐞 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞𝐬
[1.] Test First
◾ Write a failing test before writing any production code.
[2.] Incremental Development
◾ Write the minimum amount of code to pass the test, then refactor.
[3.] Red-Green-Refactor
◾ The TDD cycle of writing a failing test (red), making it pass (green) and improving the code (refactor).

The TDD Cycle -
Red => Write a failing unit test that defines a specific behavior or functionality.
Green => Write the minimum amount of production code to make the test pass.
Refactor => Improve the code's design without changing its behavior (with the test as a safety net).

📌 𝐓𝐲𝐩𝐞𝐬 𝐨𝐟 𝐓𝐞𝐬𝐭𝐬
◾ Unit Tests
- Smallest testable unit of code (functions, methods, classes)
- Verify isolated behavior and correctness of individual components
Example =>Testing a calculatePrice() function with various inputs
◾ Integration Tests
- Interaction between multiple components or modules
- Ensure components work together correctly, including data flow and communication
Example => Testing the interaction between a database repository and a business logic layer
◾ End-to-End (E2E) Tests
- The entire application flow, simulating real user interactions
- Verify that the application works as expected from the user's perspective
Example => Testing a web application by automating browser actions (e.g. clicking buttons, filling forms)
◾ Acceptance Tests
- High-level business requirements and user expectations
◾ Regression Tests
- Functionality that previously worked correctly
◾ Functional Tests
- Specific functions or features of the system
◾ Performance Tests
- System performance under various load conditions
◾ Security Tests
- Identifying vulnerabilities and potential security threats

📌 𝐓𝐡𝐞 𝐋𝐨𝐧𝐝𝐨𝐧 𝐒𝐜𝐡𝐨𝐨𝐥 (𝐌𝐨𝐜𝐤𝐢𝐬𝐭 𝐓𝐃𝐃) 𝐯𝐬 𝐓𝐡𝐞 𝐃𝐞𝐭𝐫𝐨𝐢𝐭 𝐒𝐜𝐡𝐨𝐨𝐥 (𝐂𝐥𝐚𝐬𝐬𝐢𝐜𝐢𝐬𝐭 𝐓𝐃𝐃)
L - Focus on testing interactions between objects. Emphasizes using mock objects to isolate the unit under test from its dependencies.
D -  Focus on testing the state of objects after certain actions. Prefers using real objects and stubs (simple implementations) over mocks.

L - A single class is the typical unit.
D - A module (a cohesive group of classes) is the typical unit.

L - Tests verify that the correct messages (method calls) are sent between objects, with specific arguments and in a specific order.
D - Tests check if the unit under test produces the correct output given specific input and initial state.