As Andy Aka's comment says, there is very likely more to this than a single pin for sending and receiving data, and currently the question is missing important detail. However, outlining one of the options might help you understand the detail that an answer needs.
Some examples of the type of detail which may be important, in no particular order, to answer the question:
- Data rate - how fast does the data need to be transferred?
- latency - how long can the delay be between sending and receiving data?
- is the data bit or byte orientated, and is it arbitrary binary?
- is the transfer one way or are their some use-cases which require
- e.g. can either end initiate a transfer; can Arduino 2 request data,
or is it only controlled by Arduino 1?
- e.g. will the 'slave' always be ready to receive data, or is their a
possibility that it will be unavailable or could lose data, and so
may need a retransmit?
- how many Arduino pins are available to implement the transfer
- how much CPU overhead is acceptable to achieve the data rate on
sender and receiver, is 20% available, or 10µs/byte, can either or
both ends 'block' waiting for a transfer?
- over what distance is the transfer going to happen, inches (cm),
yards (m), miles (km)?
You're outline diagram suggests that there is only a small amount of data in each transfer, but even that is not clear.
The simplest solution is to connect the Arduinos' ATmega SPI peripherals together, Arduino 1 as master, and Arduino 2 as slave. This requires at least two pins, clock and MOSI, between Arduino 1 and Arduino 2. It is the same number of pins as would be used by any synchronous shift-register based solution using external chips; the ATmegas on-board SPI peripheral is designed to implement the same mechanism.
If the transfer might sometimes be faster or earlier than the slave, Arduino 2, can use the data, then a buffer would be some RAM in the receiving (slave, Arduino 2) ATmega. Or an extra pin could be used to send data back from the slave, Arduino 2 , to the master, Arduino 1 to control the transmission rate. Flow-control would be handled in software, and not by the SPI peripheral.
The ATmega's SPI peripheral transfers 8 bits at a time, which looks comparable to your solution outline.
The ATmega SPI peripheral is synchronous, and so has a clock signal, generated by the master. The clock can stopped while there is no data to transfer. The slave SPI will set a flag when a byte has been received. So there is a way to inform the slave that data is ready.
Further, the slave SPI peripheral can raise an interrupt when a byte has been received, so an interrupt service routine running on the slave can copy the byte into an in-RAM buffer. So the transfer does not need to be limited to one byte.
Also, the master SPI peripheral can raise an interrupt when the transfer of a byte is complete, so an interrupt service routine could send multiple bytes of data from an in-RAM buffer with a relatively small overhead.
The SPI peripheral is capable of simultaneously sending and receiving data, so any 'handshaking' that the software running on the master might need to ensure it isn't sending data too fast can also be implemented in your software.
Also, because the SPI peripheral data rate can be up to 4Mbit/second the data rate is higher than an asynchronous transfer, and is as quick as the ATmega could transfer data over any serial connection to an external device. Further, the latency (time lag) between sending data from the master to the slave can be quite low, at a few clock cycles over 2µs. At this rate, it might make sense to send smaller amounts of data if the data transfer needs are less than a byte at a time.
Finally, the SPI peripheral also supports an enable or select signal, so that more than one slave device can be driven by one master.
Of course, all of this could be implemented in software, without the use of the SPI peripheral, but using only digital read and write of GPIO pins. Some benefit would be a software approach could use any available pins, and the transfer wouldn't need to be byte orientated, or use a byte-size 'packet. Software will transfer more slowly, and have a larger CPU overhead than the hardware SPI peripheral, but it is more flexible.