A useful architecture diagram explains where a system is going. A useful implementation guide helps someone sit down, write the first line and know what “done” means at every stage.
We have now documented the build path for api.lejiend.com. The guide translates our planned backend architecture into practical steps for Python, FastAPI and Cloudflare Workers, supported by D1, Queues and Turnstile.
This is also part of how we want to build in public: sharing not only what we intend to create, but practical knowledge about how we execute, validate decisions and reduce risk before changing a live customer journey.
What the guide covers
One API boundary, two kinds of trust
The first version has three public routes: a health check, an enquiry endpoint and a subscription endpoint. Customer enquiries and marketing consent remain separate. Sending a question to Lejiend must never silently place someone on a promotional list.
Validated submissions will receive an event ID and enter a Cloudflare Queue. A consumer will persist them to D1 before independently notifying FormSubmit and Microsoft Teams. Because queue delivery can happen more than once, database writes and notification listeners are designed to be idempotent.
The database preserves purpose
Enquiries
Immutable customer or client questions, contact details, source and event identity.
Subscribers and consent events
One normalized subscriber identity with append-only records of consent, renewal and withdrawal.
Notification deliveries
An audit of attempts and outcomes so successful destinations are not called again during a retry.
Four controlled stages
The current forms will continue using FormSubmit until the new API passes its verification gates. Documentation is progress, but it is not production capability. We will keep that distinction visible as we build.
Our next move is deliberately small: create the Worker foundation, define the event envelope, apply the first local D1 migration and prove that one synthetic enquiry can safely reach the Queue.











