Coming from Web2, I initially thought of a Solana transaction like an API request:
send request -> server processes it -> get response
But after working with Solana transactions, I realized the mental model is quite different.
A Solana transaction is a package containing things like signatures, instructions, accounts, and a recent blockhash. The transaction is signed before it can be accepted, and the instructions describe exactly what the network should execute.
One thing that really clicked for me was the idea of atomicity.
With an ordinary API, I might send a request to my backend and then update a database. There can be multiple steps involved.
With a Solana transaction, multiple instructions can be included together, and they are executed atomically. The transaction either succeeds as a whole or fails.
I also learned that transactions aren't valid forever. They use a recent blockhash, which gives them a limited validity window. That was very different from the API requests I'm used to working with.
During my experiments, I also ran into a 429 Too Many Requests error while polling transaction status. That was a useful reminder that even when the blockchain is decentralized, my application still depends on RPC infrastructure to communicate with it.
The biggest takeaway from Day 20:
A Solana transaction isn't simply a request to a server. It's a signed set of instructions that asks the network to make an atomic state change.
That shift in thinking is making Solana development start to feel much clearer.
