Skip to main content

Resilience

Jurisdictions​

Your data stays in the jurisdiction you choose. A jurisdiction is two cloud regions inside it, far enough apart that one event does not take both.

JurisdictionEndpointRegions
Australia and New Zealandanz.api.patternode.comTwo, in Australia and New Zealand
European Unioneu.api.patternode.comTwo, in the EU
United Statesus.api.patternode.comTwo, on the east coast and in the centre
Anyapi.patternode.comRoutes to your account's home jurisdiction

Patternode keeps none of your series, segments or edges at all. It MUST NOT process them outside your jurisdiction. Support staff outside it MAY see metadata (request ids, counts, error codes), never series.

How it stays up​

Patternode keeps no series state, so every region and every instance can answer every call. Resilience is a matter of capacity and routing, not of moving state.

PlanWithin a regionAcross regions
ProductionThree zones; losing one zone is invisible to youA second region of the jurisdiction takes the traffic within 4 hours
Mission Critical, DedicatedThree zones, as ProductionActive-active: both regions serve your account all the time

Your traffic runs in a cell: a slice of the service with its own capacity, so another account's surge cannot use yours. Dedicated cells serve one account.

What you see in a failover​

EventRESTgRPC streamWebhooks and event buses
A zone failsNothingNothing, or a reconnectNothing
A region fails (Mission Critical, Dedicated)Requests move to the other region within 60 seconds; requests in flight may fail with 503 and are safe to resend unchangedThe connection gets GOAWAY or resets; reconnect and resend the requests not answeredDeliveries pause and resume from the other region; duplicates are possible
A region is degraded but upPatternode MAY drain it; you see the same as a failover, without errors

You MUST make your client follow these: resend unanswered requests unchanged, with backoff; reconnect gRPC streams; deduplicate events by id. Because your edges are in your store, nothing about your series is lost in any failure of Patternode's. The example clients do this.

Degraded modes​

If a dependency fails, the service sheds what it can and keeps what matters most, in this order:

  1. Extensions of forming series.
  2. Finished series answered inline.
  3. Event delivery.
  4. Jobs. Queued jobs wait; none is lost.
  5. Reports and account changes.

Recovery objectives​

ProductionMission Critical, Dedicated
Your series' data lost in any Patternode failureNone: Patternode holds noneNone
Recovery time, region loss4 hours60 seconds
Recovery time, loss of a jurisdiction's both regionsBest effort24 hours
Account data (keys, settings, usage), recovery point5 minutes1 second

Change control​

ProductionMission Critical, Dedicated
ReleasesProgressive: a cell at a time, watched, rolled back automatically on regressionThe same, and never during your blackout periods
Blackout periodsNoneYou set them: for example the trading hours of your venues, or a storm or emergency declared by your operator. Patternode MUST NOT release to your cells inside them, except to fix a Severity 1
Notice of change to the platformChangelog5 business days, by email, for anything beyond a fix
Engine versionsFixed per profile version (Determinism)The same

Testing​

Patternode MUST, every quarter, fail a region of each Mission Critical jurisdiction in production and publish the result to Mission Critical and Dedicated customers. Dedicated customers MAY take part, and MAY run their own resilience tests against their cells with 10 business days' notice.

Exit​

You can leave at any time with everything that is yours:

  • Your segments and edges are already in your store; Patternode holds nothing of your series.
  • Usage and audit logs export as files.
  • Mission Critical and Dedicated customers get an exit plan in the order form, and Dedicated customers a tested one, with transition support for 6 months.