Profiling a simple binary bet from deployed dev api

• 550ms

  • 300ms for transactions to start and end
    • 200 ms to start
      • 150 postgres tx
      • 50 firestore transaction
    • 100 ms to end
  • 35ms per firestore query
    • Getting the contract
  • 30ms per postgres query
    • Getting the user (who is betting)
    • Get unfilled limit orders
    • Get balance of users in limit orders
    • Insert bet
    • Increment balance
    • Increment creator balance (from fee)
    • Get your bets (for redeem shares)

• Profiling a simple binary bet from a local server.

Tested a version of placebet with no transactions or firebase and it was 218ms

• So the 300ms of transaction latency is real.

Analysis

• The migration will eliminate ~100ms for the firestore transaction

• The remaining supabase transaction is ~200ms.

  • We do have the queue, which could help us remove this transaction.
  • Could have some kind of eventually consistent based on whether the insert bet goes through or not.

• If we remove the transaction

  • People could double-spend by betting on two markets at the same time

    • But it would have to be with someone betting on your limit order in another market and then you betting, or else queue would not let them happen together.
    • So, if queue included all the limit order deps, then this would be fine
    • But, same for every financial transaction:
      • Make runTxn go through the queue?
        • So when you subsidize a market, or pay to create a market,

  • One part of the transaction could error, e.g. creating the bet, while another part succeeds, decrementing your balance. How do we fix that?

    • We can execute all the writes together with pg multi

    // Get data from 2 tables in a single request:
    const [users, products] = await pg.multi('SELECT * FROM users; SELECT * FROM products');
    

• [J] It seems like moving the database to be colocated will revolutionize the latency of our app. We should do that and then check this stuff again.