Fullstack

HTTP Status Codes

• 200 OK - Success
• 201 Created - Resource created
• 204 No Content - Success, no response body
• 400 Bad Request - Client error
• 401 Unauthorized - Authentication required
• 403 Forbidden - Access denied
• 404 Not Found - Resource doesn't exist
• 409 Conflict - Resource conflict
• 422 Unprocessable Entity - Validation error
• 500 Internal Server Error - Server error

Because automated release process is often preceded by automated testing, CI/CD are used together and enable application deployment any time by clicking a button.
Read more: https://www.redhat.com/en/topics/devops/what-is-ci-cd

• CI (Continuous Integration) allow changes to central repository, and often trigger automated test suites.
• CD (Continuous Delivery/Deployment) allows deployment after code changes to an environment after the build stage. Some deployment strategies may look like:
  • Blue-Green: Two production alternating servers.
  • Canary: Slow feature adoption.
  • Rolling updates: Linear service upgradation.

Databases

• Concurrency
  • Serially
  • Serially Batch
  • Pessimistic Locking
  • Optimistic Locking
• Resource Locking

CAP Theorem: A modern (distributed) database system can only guarantee 2 out of 3:

• Consistency: All nodes see same data simultaneously. Every read receives the most recent write or an error.
  • Strong Consistency: Strong consistency ensures that all replicas in a distributed system have the same view of data at all times.
  • Weak Consistency: Weak consistency allows temporary inconsistencies or delays in data synchronization across replicas.
  • Eventual Consistency: Eventual consistency guarantees that if no further updates are made to a data item, eventually, all replicas will converge and become consistent.
• Availability: System remains operational. Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
• Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes

Which leads to different implementation ideologies

• ACID Properties: (consistency over availability)
  • Atomicity: All or nothing transactions.
  • Consistency: Data integrity maintained.
  • Isolation: Concurrent transactions don't interfere.
  • Durability: Committed data survives system failures.
• BaSE Properties: (availability over consistency)
  • Basically available: Transaction is not blocked by other.
  • Soft state: Transient or temporary states allowed.
  • Eventually consistent: Consistency on concurrent completion.

Read more: https://aws.amazon.com/compare/the-difference-between-acid-and-base-database/

Some popular databases:

• MariaDB: MySQL-compatible relational DB with enhanced features | Docs
• MongoDB: Document-based NoSQL database | Docs
• Postgres: Advanced open-source relational database | Docs
  • TimescaleDB: Time-series extension for PostgreSQL | Docs
• Redis: In-memory data store for caching & sessions | Docs
• Cassandra: Wide-column NoSQL for big data | Docs
• neo4j: Graph database | Docs
• Other Databases
  • CockroachDB: Distributed SQL database | Docs
  • CouchDB: Document DB with HTTP API | Docs
  • PouchDB: Client-side CouchDB | Docs
  • DuckDB: Analytical SQL database | Docs

Consistency - Availability: []_- : MySQL

Availability - Partition-Tolerance: []_- + []_- : CouchDB

Consistency - Partition-Tolerance: []-[]-[]_- : Redis

Additional Database types:

• Realtime Data: Columnar. Eg. Autocomplete, Notifications.
  • Kafka
  • RabbitMQ
  • Postgres CDC
• Geological / Spatial Data: Eg. OpenStreetMap
  • Solr
  • Typesense

API

API service should provide a clear error messages (& correct HTTP status code). A request validation allows for better structure, and versioning allows introduction of new features without breaking existing ones. Eg, /v1/resource.

• Polling vs Webhooks: Polling requires client to request data periodically, where webhooks captures data when server emits events.
• BFF (Backend for Frontend): Optimize backend for specific client interfaces.
  Read more: https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends

API Variants: ??

• REST: Stateless endpoints that leverage HTTP Methods. Each request should contain all the necessary information for processing(via query-params, body, or headers),

  GET    /api/users          # List users
  GET    /api/users/123      # Get specific user
  POST   /api/users          # Create user
  PUT    /api/users/123      # Update user (full)
  PATCH  /api/users/123      # Update user (partial)
  DELETE /api/users/123      # Delete user

• WebSockets: Real-time bidirectional communication.

• SOAP: ??

• GraphQL: ??

• RPC

  • tRPC
  • gRPC: High Performance and Type-Safety

• Messaging Queue: Async Event-driven Architecture.

System Architecture

Transactional Messaging and Event-Driven Architecture.
Read more: https://medium.com/@platform.engineers/transactional-messaging-and-event-driven-architecture-a-technical-overview-f96a23d7aa26

Important to build Zero-Trust Architecture

While it is a good practice to add a Gateway / Load Balancer in front of a service, it should also provide additional features:

• Security: Zero Trust Network. SSL-first.
• Connection Pool: Reuse connections to database.
• AllowList: Prevent unknown access
  • CORS: Cross-Origin Resource Sharing
• Rate Limiting: Prevent over-usage.

To improve QPS or CPU usage to handle incremental load, systems evolve to become more complex.
Read more: https://aws.amazon.com/what-is/scaling/

• Vertical Scaling: Add more power (CPU, RAM) to existing machine.
• Horizontal Scaling: Add more machines to the pool. Requires load balancing and service coordination:
  • Load Balancer: Distribute incoming requests across multiple servers
    • Round Robin: Requests distributed evenly
    • Least Connections: Route to server with fewest active connections
    • IP Hash: Route based on client IP
    • Weighted: Distribute based on server capacity
  • Connection Pool: Split monolith into independent "micro-services", and reuse database connections to reduce overhead.
  • Database Optimization:
    • DB Cache: Redis, Memcached for faster data access.
    • DB Replication: Read replicas for load distribution.
    • DB Sharding: Horizontal partitioning of data.
      Read more: https://www.digitalocean.com/community/tutorials/understanding-database-sharding
    • CQRS: Command Query Responsibility Segregation.
      Read more: https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs

Backend as a Service (BaaS)

• Supabase: Open-source Firebase alternative with Postgres
  Read more: https://supabase.com/
• PocketBase: Single-file Go backend with admin UI
  Read more: https://pocketbase.io/
• Appwrite: Self-hosted backend server for web & mobile
  Read more: https://appwrite.io/

Platform as a Service (PaaS)

• Coolify
  Read more: https://coolify.io/
• CapRover
  Read more: https://caprover.com/
• Netlify: JAMstack deployment with edge functions
  Read more: https://netlify.com/
• Railway
  Read more: https://railway.app/
• Render
  Read mre: https://render.com/

Essential External Resources

• The Twelve-Factor App
• AWS Well-Architected Framework
• Docker Best Practices
• Microservice Architecture