Fooodo arhitektūra

Fooodo darbojas kā divi savstarpēji sadarbojoši pakalpojumi kopā ar ārēju POS, kas ir sasniedzams caur POS-neatkarīgu savienotāja līgumu. Šī lapa ir sistēmas karte: kā elementi savienojas, kāpēc tie ir sadalīti un kā darbojas daudzīrniecība.

Divi pakalpojumi

• Izvēlnes lietotne. Klientam paredzētā plūsma (QR → pārlūkošana → pasūtījums), operatora administrācijas panelis un viss POS savienotāja datplūsma.
• Maksājumu pakalpojums. Atsevišķs pakalpojums aiz ar marķieri autentificēta API. Pārvalda Mollie integrāciju, tīmekļa āķu maršrutēšanu, ziedojumu maršrutēšanu un dzeramnaudas maršrutēšanu. Tam ir sava iekšējā administrācija.
• POS savienotājs. Jebkurš POS, ko restorāns izmanto. Fooodo uzskata to par izvēlnes ierakstu sistēmu un par virtuves patiesības avotu pasūtījumiem. R-Keeper ir aktīvais atsauces savienotājs šodien; citi POS savienotāji tiek noteikti katram klientam atsevišķi — pats savienotāja līgums ir POS-neatkarīgs.

Abi Fooodo pakalpojumi sazinās caur autentificētu HTTP API; nav kopīgas datubāzes, nav kopīgas rindas un nav kopīgas izvietošanas vides. Tos var izvietot neatkarīgi.

Kāpēc maksājumu pakalpojums ir atdalīts

Trīs iemesli:

1. Atbilstības tvērums paliek mazs. Kartes dati jebkad pieskaras tikai maksājumu pakalpojumam; izvēlnes lietotne saņem norēķinu URL un atsauces izsaukumu. PCI tvērums ir ierobežots līdz vienai kodu bāzei.
2. Maksājumu pakalpojums ir atkārtoti izmantojams. Tas tika izstrādāts, lai laika gaitā apkalpotu vairākas Fooodo virsmas, nevis tikai pašreizējo izvēlnes lietotni. Jauni produkti to izmanto, neievieš atkārtoti maksājumu infrastruktūru.
3. Kļūmju izolācija. Ja Mollie ir reģionāls pārtraukums, izvēlnes lietotne turpina darboties; pasūtījumi rindojas stāvoklī "gatavs apmaksai" un tiek saskaņoti, kad maksājumu pakalpojums atjaunojas.

Daudzīrniecība

Katrs ieraksts izvēlnes lietotnē ir tverts caur šo hierarhiju:

• Uzņēmums ir īrnieka robeža. Pašlaik viens aktīvs uzņēmums ražošanā (Čili Pizza), taču īrnieku atdalīšana tiek nodrošināta visur — otrās ķēdes pievienošanai nav nepieciešama atsevišķa izvietošana.
• Restorāna administratori var pārvaldīt tikai savu restorānu — lomu sistēma to nodrošina politikas līmenī.
• Katrs QR kods atrisina uz konkrētu galdu konkrētā restorānā. Nav kopīga "skenē, lai pasūtītu" koda; Fooodo vienmēr zina, kurai vietai pasūtījums ir paredzēts. Tas ir tas, kas padara iespējamu vēlāku apmaksu (Pay-Later), rēķina sadalīšanu pie galda un analīzi vietas līmenī.

Kur atrodas UVS

UVS ir pasūtījumu un operāciju kodols izvēlnes lietotnē — centrālā notikumu plūsma, kas reģistrē visu, ko platforma raksta (pasūtījumus, maksājumus, galda stāvokli, virtuves biļetes), pirms izplatīšanas patērētājiem (aktīvajam POS savienotājam, maksājumu pakalpojumam, nākotnes moduļiem).

Integrētājiem tas ir konkrēti svarīgi: moduļi nerunā viens ar otru tieši, un līgums ir POS-neatkarīgs. Savienotājs jaunam POS nepieskaras virtuves plūsmai vai maksājumu pakalpojumam — tas runā UVS līgumā un automātiski iegūst maksājumus, daudzīrniecību un atskaites. R-Keeper ir viena šī līguma ieviešana; pats līgums ir sistēma. Līgums ir dokumentēts integrācijas repozitorijā, ko partneri saņem uzņemšanas laikā.

Steks īsumā

Konkrētas ietvara versijas ir apzināti izlaistas no šīs publiskās virsmas — partneri, kas veido POS savienotājus, saņem versiju piespraudumu uzņemšanas laikā kopā ar integrācijas repozitoriju.

Kas atrodas kur

• Izvēlnes pārvaldība, pasūtījumi, galdi, klientam paredzētā plūsma → izvēlnes lietotne.
• Kartes dati, maksājumu metodes, dzeramnaudas, ziedojumi → maksājumu pakalpojums.
• Izvēlnes patiesības avots, virtuves biļetes, atskaites → jūsu POS (šodien R-Keeper, citi savienotāji, kad tie tiek piegādāti).
• Mārketinga teksts, publiskie dokumenti, AI asistents, MCP serveris → šī vietne.

Ja integrējaties ar Fooodo, API virsma, kas jums ir svarīga, ir izvēlnes lietotnes ārējais API. Maksājumu pakalpojums ir iekšējs — izvēlnes lietotne darbojas kā starpnieks uz to.