SPI receive flow is continuous: additional bits keep coming in regardless of what you do with them. That is, SPI has no mechanism for backpressure to limit the input data rate (unlike I2C, which can slow down the bus by using clock stretching).
You can divide the SPI receive process as follows:
- accumulate (deserialize) a data word
- notify the receiving host of a completed word (handshake)
- receiving host transfers completed word to storage
In theory, if the host is fast enough (or SPI is slow enough), the receiving host could just count the clocks, then grab the deserializer register state when the right number of clocks has occurred. At the extreme case this could be done entirely in software using 'bit-bang' techniques, by polling the clock and data pins.
In practice, SPI is so fast that usually the receiving host has some form of buffering to allow time to capture and store the incoming data word. The faster the data (or slower the host), the more buffering is needed to cover the host's response latency. Further, SPI bit reception is handled by dedicated deserializer hardware with well-controlled low-level timing.