• https://www.youtube.com/watch?v=iB78FrFWrLE
• AWS
  1. Memory optimised : high memory, less CPU
  • Examples:
    • r7, r6, x2idn, u-6tb1
    • In-memory databases (Redis, Memcached)
    • Real-time big data analytics (Apache Spark, Presto)
    • High-performance databases (SAP HANA)
  1. Networking Optimised: enhanced networking (via ENA or EFA) and high-throughput across instance types. Examples
     • c7gn, m7i-flex, i4en
     • Distributed applications (HPC, ML training)
     • Large-scale databases or clustered file systems
     • Low-latency trading systems

1. Instance Store Volumes (a.k.a. Ephemeral Storage)
   • Storage that is physically attached to the host machine.
   • Much faster than EBS for local I/O.
   • You need very fast, temporary local storage (NVMe SSDs).
   • You can tolerate data loss or sync to durable storage elsewhere.
   • Only available on some instance families, like:
     • i3, i4i, d3, h1, z1d, c5d,
   • Use cases:
     • High-speed caches: Local cache for web servers, CDN nodes.
     • Scratch space for:
       • Video transcoding pipelines (temporary intermediate files)
       • Large dataset transformations (Hadoop temp storage)
     • NoSQL/OLTP databases that replicate (e.g., Cassandra, MongoDB) — each node uses fast local disks and replicates data.
     • Build servers (e.g., CI/CD pipelines) — fast local disk for compiles/tests.
     • Distributed storage systems (e.g., Ceph, GlusterFS) where instance store backs the volume and higher-level software handles durability.

Coinbase Architecture

1. Client orders - API or UI
2. Network Load Balancer
3. Client API Gateway Layer
   1. Authentication, rate-limiting, validation, and routing client orders to backend services.
   2. Prevents unauthorized access, protects backend systems from DDoS attacks or overloads.
   3. Example: Gateway authenticates API key, validates order parameters, and forwards order to OMS.
4. Order Management System (OMS): Validates, tracks, and manages lifecycle of orders (submission, cancellation, updates).
   1. Why Needed? Ensures orders are valid, complies with business logic and regulations.
   2. RAFT Consensus: OMS maintains distributed consensus (via Raft), ensuring orders are reliably recorded even if a node crashes. WHY?
   3. Example: OMS checks if user has sufficient balance, then forwards the order to the matching engine.
5. Matching Engine: Matches buy and sell orders in real-time based on defined algorithms (e.g., price-time priority).
   1. Matching Engine processes the logic of matching orders. The order book itself is just a storage structure reflecting current open orders. Matching Engine updates the order book state.
   2. Entire order book kept in memory (RAM) for extremely fast access.
   3. Event-driven, message-passing architecture
   4. Price-time priority matching.
   5. Matching logic is usually single-threaded per trading pair to avoid locking overhead.
   6. Parallelism achieved by sharding order books by trading pair (BTC/USD, ETH/USD, etc.).
6. In-Memory Order Books: High-performance in-memory data structures holding all open orders, constantly updated by Matching Engine. After match, buy/sell order is removed or updated instantly in memory. Reflects real-time bid/ask.
   1. Updates published immediately to market data streams
   2. Usually stored in RAM using efficient structures (e.g., sorted arrays, red-black trees).
   3. Disadvantage: Volatile; data lost on crashes/restarts
   4. Regular snapshots and continuous event logging (journaling, WAL) for persistence and recovery.
   5. Upon restart/crash, order book state is replayed from persisted logs/snapshots.
   6. Permananet state (post trade) is stored in Amazon Aurora
7. Event Journal (WAL - Write-Ahead Log): Persistently logs every event (order creation, cancellation, matching, trade execution) to disk. Provides auditability, data integrity, and facilitates rapid recovery in case of system failure.
   1. If a matching engine crashes, event journal replays logged events to rebuild the correct order book state quickly.
8. Market Data Distribution (Oracle): Publishes order book updates and market/trade events to subscribers (traders, market makers, partners). Ensures market transparency and real-time data delivery to external parties. Sends live updates (price, trade volume) to Coinbase WebSocket clients and market makers.
9. Settlement & Clearing System: Ensures executed trades are settled, and funds/assets transfer between buyer and seller, ensures compliance with regulatory requirements.
10. Custodial Wallets / Ledgers: Securely stores and tracks crypto and fiat assets for customers.
11. Aeron: is a low-latency, high-performance messaging system, specifically designed for financial trading environments. Provides ultra-low latency, high throughput communication between OMS, Matching Engine, Journaling, and Market Data Distribution. Enables robust asynchronous messaging, critical for handling millions of events per second reliably.
    1. Sub-microsecond latency.
    2. High throughput (millions of messages/sec).
    3. Persistent message logs (journals).
    4. Designed for event-driven, asynchronous communication.
12. Persistent DB (for snapshots): Used for regular snapshots of the in-memory order book.Optimized for rapid writes, quick restoration, and minimal latency. Example RocksDB, Cassandra or LevelDB. These DBs handle:
    1. Frequent writes with minimal overhead.
    2. Sequential append-only operations (ideal for snapshots/logging)
    3. Fast state-rebuild capabilities during crash recovery.
13. Permanent DB (for trades, user balances, compliance): Long-term storage for auditability, compliance, trade history, and regulatory reporting. Typically relational databases (like AWS Aurora) to ensure durability, transactional consistency (ACID), and strong querying capabilities. For
    1. Trades & orders
    2. User balances & wallet details
    3. Compliance records
    4. Historical transactions & reporting data