Why can a reader and a tag never speak at the same time?
The reader provides the field that keeps the tag alive, and the tag answers by modulating that same field. There is only one channel and one energy source, so the two sides must take turns. Every exchange is strictly question and answer, never both at once.
Why the channel can only carry one voice
The reader is not merely a correspondent, it is the power supply. Its field has to stay up continuously or the tag stops existing electrically. The tag cannot take over the channel, because doing so would mean cutting the branch it sits on.
So the tag answers the only way it can: by varying how much it draws from that field. The reader is simultaneously talking, powering and listening, and the tag can only reply in the gaps the reader leaves.
What a round trip costs
Each exchange is a question, a pause, an answer, and another pause before the next question. Those pauses are small, but they are per round trip rather than per byte.
The consequence is counterintuitive: two hundred bytes in one exchange are faster than two hundred bytes split across five. Bandwidth is not the scarce resource in NFC, turn taking is.
Why many small records read slowly
A tag holding one record with a web address is read in a handful of exchanges. The same content split across six short records carries more header bytes, so it needs a few more exchanges and spends a little more of its time waiting between them.
This is worth knowing before designing a tag's content. If a tap feels sluggish, the useful question is how many separate things the phone had to ask for, not how many bytes came back.
What happens when a turn is cut short
Move the phone mid exchange and the tag loses power between a question and its answer. There is no buffering and no resume: the sequence simply stops.
For a read this is harmless, you get nothing and try again. For a write it is not. The tag may hold the beginning of a message and nothing else, in a state that reads as corrupt rather than as empty. This is the mechanical reason behind the advice to verify a write rather than trust that it succeeded, and the reason a batch of tags written quickly should be checked before shipping.
Frequently asked questions
Could a tag interrupt the reader if it needed to?
No. It has no way to signal anything outside the field that powers it, and no authority over the channel. A tag can only answer, and only when the reader has left room for an answer.
Is this why NFC is slower than its bit rate suggests?
Largely, yes. The defined rates describe the channel while it is carrying data, and a real exchange spends much of its time in the pauses between turns. The effective throughput of a read is well below the nominal figure.
Does the same limitation apply to card emulation?
Yes. When a phone emulates a card it takes the role the tag would have had, answering an external terminal that supplies the field. The turn taking is identical, only the roles are swapped.
Should I verify every write?
For anything going into production, yes. A write cut short mid sequence leaves a tag that looks written and is not, and the cost of checking is a second per tag against the cost of a thousand unusable ones.