CedarPointCedarPoint
How to move from a vague brief to a scalable architecture — by finding your requirements and constraints first. Today we do it live.
No slides walking you through a finished answer. I give you a problem that doesn't exist yet — and we design it together, live, on the board.
Before a single line of schema or code, you need your requirements and constraints. Skip that step and you build the wrong thing — faster.
You pull the answer out through questions, tradeoffs and pushback — the same way a real spec forces you to.
The subject is CedarAccess. The lesson is the thinking. It transfers to every module you'll ever build.
That's the whole thing. No constraints given yet. Before anyone touches a whiteboard — what do you need to know?
I only answer what you ask. Nobody hands you constraints in real life — you interrogate the problem until it gives them up. Questions worth reaching:
A door opening because the network dropped is never acceptable. This alone kills any design where the door waits on the cloud at scan time.
The business needs "correct within a bounded window," not real-time consistency across branches. A far easier problem — once you admit it.
ZKTeco readers over TCP/IP, a local bridge per branch. Not up for debate — the design works with it, not around it.
Lebanon's power and connectivity reality makes this decision for you. Environment is a first-class input — same as it was for TrackMe and Pointverse.
Given all of that: local bridge per branch, fail-secure, eventual sync, cloud owns membership. Show me the shape. Steer with these:
Locally or centrally — and why? If a scan waits on the cloud, what breaks the moment the line drops?
If it hasn't reached the cloud in 6 hours, how does it still approve the right people?
Both mark the same member "checked in." When they reconnect — is that even a conflict?
Separate the "must be right now" from the "can wait." Most of it can wait.
Same shape as POS systems, ATMs, and airline kiosks: local authority for the low-latency high-stakes call, async reconciliation for everything else. Events are append-only — so there's barely a conflict to resolve.
Here's how CedarAccess is actually planned. Tell me where you matched it — and where you went a different, still-valid way.
Draw boxes before you know the constraints and you'll design the wrong system — faster.
Fail-secure vs fail-open decided half of this design on its own.
Membership: right eventually. A door decision: right now, locally. Treating everything as "sync instantly" is the common overcorrection.
Power and connectivity are first-class inputs — not a workaround you bolt on later.
Local authority + async reconciliation shows up everywhere. See it once, recognize it forever.
Before you open Prisma — ask these same questions first. That's the skill from today.