Beaver infrastructure
Built for the rush.
Competition traffic does not always arrive politely. A big prize launches. A campaign lands. Closing time approaches. Everybody turns up at once.
Beaver is designed so ordinary storefront traffic stays light while the important transactional paths remain controlled.
Built to hold up.
The principle
Do not make every page view expensive.
The storefront does not need to hit the application database for every piece of content it serves.
Live Beaver uses cached HTML at the CDN edge, with live counters able to update separately. Checkout remains the critical path that needs database interaction.
Keep the public path light. Keep the important path controlled.
-
Edge serving
Put cacheable content closer to the visitor.
Competition storefront HTML can be served from the CDN edge, which reduces unnecessary work on the application for ordinary public page delivery.
Architecture first. Hero numbers later.
-
Live data
Cached does not have to mean stale.
Live counters are punched through the cached page rather than forcing the whole page to become dynamic.
-
Checkout
Keep the database for the work that needs it.
Checkout is the critical transactional path, where Beaver handles the state that cannot simply be cached away. Public browsing and transactional work are deliberately separated.
Not every click deserves a database query.
Tenant provisioning
Create the operator environment automatically.
Live Automatic tenant provisioning. From the operator setup flow the platform creates domain handling, the storefront, legal pages, a mail sender and an isolated runtime.
A new operator should not require a new server project.
Process isolation
Operators share the platform, not the runtime process.
Each operator's code runs as its own user and in its own process pool. The application also refuses to serve an unknown host where no operator is associated with the request. That gives process and resource separation between operator runtimes.
The database is shared, by design
We are not going to hide that. It is intentional, in part because cross operator exclusion depends on shared visibility at the relevant data layer.
Isolation where it matters. Shared state where the product requires it.
-
Suspension
Live
A suspended operator is served a holding page rather than normal competition content. A controlled state, not manual server work.
-
Unknown hosts
Live
If Beaver does not know the site, it does not serve it. Small feature. Good engineering signal.
-
Monitoring
Live
Error reporting is tagged with the operator that produced it.
An error without context is just noise.
-
Backups
Live
Nightly offsite backup. The database leaves the primary environment every night. Recovery promises come after the recovery process is documented.
Unattended operation
Keep working when nobody is watching.
Current automated jobs include:
- Draw processing, every minute
- Cart release, every minute
- Journey processing, every five minutes
- Player profile work, hourly
- Membership rebilling, nightly
The platform keeps working after the operator closes the laptop.
| Competition | Entries | Stage |
|---|---|---|
| Example competition A | Committed | Awaiting randomness |
| Example competition B | Committed | Drawn, verifiable |
| Example competition C | Open | Scheduled |
Illustration of draw stages with example competitions.
The plumbing
What is live, what is built, what is not.
| Capability | Status | What that means |
|---|---|---|
| Edge cached storefront HTML | Live | Live counters update separately. |
| Automatic tenant provisioning | Live | Storefront, legal pages, mail sender, isolated runtime. |
| Per operator process isolation | Live | Own user, own process pool. |
| Nightly offsite backup | Live | No RPO or RTO promise until the recovery process is published. |
| HMAC signed webhooks | Built | Per event subscriptions, retry with backoff, delivery logging. Not yet proven with broad third party use. |
| Scoped API tokens | Built | The public REST API is not ready to sell. |
| Selectable data residency | Not available | A registry control exists but does nothing yet. A settings label is not infrastructure. |
| Public status page | Roadmap | Specced. When it exists it joins the Trust Centre. We will not link to a fake one. |
Live proven on the deployed platform. Built in the product with passing tests, not yet proven with live customers. Roadmap planned, not a working feature.
The plumbing exists. The public tap is not ready.
High traffic claims
Designed for pressure. Not pretending we have history we do not.
Beaver has an architecture intended to reduce public request load and protect critical paths. That lets us say: built for traffic spikes, edge served storefronts, critical transactional paths isolated.
We do not yet say "proven at one million concurrent users", "powers £50 million of annual ticket sales" or "zero downtime under sell out load". Not until real evidence exists.
- We will publish the number when we have earned the number.
Under the hood
Want to see how Beaver is put together?
Talk to the people who build it.