Does Deta Base guarantee any ordering or consistency when concurrent requests write the same key?

I'm designing a small app on Deta Space that uses Deta Base as its data store, and several request handlers can end up writing to the same key at roughly the same time (for example, incrementing a counter or updating a shared record). I want to understand what behavior I can rely on before choosing between a last-write-wins design and building my own coordination.

The public documentation covers the SDK operations (put, get, delete, query) and pagination via the last key, but I haven't found a clear statement about locking, transactions, or isolation when multiple parallel writers target one key. It's also unclear whether latency or throttling under concurrent load is documented anywhere as a platform limit, since Space runs apps on shared infrastructure.

Assume a current Space SDK version; exact rate-limit numbers seem to shift between doc revisions, so I'd rather anchor on documented semantics than benchmarks.

Does Deta Base document any ordering or consistency guarantee for concurrent writes to the same key? Are there documented rate limits or concurrency caps that would explain latency appearing only under parallel load? And is there a recommended pattern (e.g., fetch-then-put) that the docs endorse for safe updates?