Architecture questions to ask: backend, concurrency and testing
Three questions that decide whether a platform survives a busy day: how many backends, what happens on a retry, and what was tested before launch.
- Shared entities and real-time consistency favour one backend for a first release.
- Enforce access in the data layer, not in each client.
- Idempotency keys, version-guarded writes and transactions guard against retries and overlaps.
- Test the safeguards themselves, and list what is still open.
Quick answer
Ask three things. One backend or several, and where do access rules live? What happens when a request is retried or two people change one record? And what was tested that a single user doing the happy path wouldn't reveal? Good answers name specifics: row-level security, idempotency keys, transactions, concurrent test runs.
Question 1: one backend or several?
If surfaces share entities and must stay consistent in real time, one shared backend usually wins for a first release. Our clinic-queue platform has five surfaces on one Supabase backend, hosted in Mumbai: a Flutter patient app, plus reception, doctor, admin and public web surfaces in Next.js. App, web and database live in one repository. Every table has row-level security and real-time channels are scoped per clinic and per doctor. The trade-off is a single thing to secure, and no performance number has been measured. Full criteria: one backend for the app and the web.
Question 2: what happens on a retry, or an overlap?
Booking and queue advance require an idempotency key and a version-guarded write, so a retried tap can’t book twice. A multi-row change should be one transaction. Our own review found a queue advance made of separate writes. The transaction fix passed 48 assertions and two concurrency runs locally. It isn’t in production. Pattern: how to prevent double bookings.
Question 3: what did you test?
Test concurrent use, repeats, limits, permissions and the release order. We found a limiter that blocked nothing and a release step that could run out of order, both by testing. Checklist: how to test before real users arrive.
Single-user tools and small internal sites don’t need this machinery. And everything above is built and tested on a demo clinic. Nothing has been proven under real clinic load.
Next chapter: Data, security and compliance.
More by GarunaCDX
Keep going with the next handbook.
Chapter-by-chapter guides from the engineers who build these systems for clients.
