Fooodo arhitektūra

Fooodo darbojas kā divi savstarpēji sadarbojoši pakalpojumi kopā ar ārēju POS, kas ir sasniedzams caur no 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ūsmas apstrāde.
• 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 to uzskata par sistēmu, kas ir patiesības avots izvēlnei, un par virtuves patiesības avotu pasūtījumiem. R-Keeper šodien ir aktīvais atsauces savienotājs; citi POS savienotāji tiek noteikti katram klientam atsevišķi — pats savienotāja līgums ir no 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 neliels. Karšu dati jebkad nonāk tikai maksājumu pakalpojumā; izvēlnes lietotne saņem norēķinu URL un atzvanīšanu. 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, neieviesot maksājumu infrastruktūru no jauna.
3. Kļūmju izolācija. Ja Mollie ir reģionāls pārtraukums, izvēlnes lietotne turpina darboties; pasūtījumi tiek ievietoti rindā stāvoklī "gatavs apmaksai" un tiek saskaņoti, kad maksājumu pakalpojums atjaunojas.

Daudzīrniecība

Katrs ieraksts izvēlnes lietotnē ir ietverts šajā hierarhijā:

• Uzņēmums ir īrnieka robeža. Pašlaik ražošanā ir viens aktīvs uzņēmums (Č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 norāda 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, rēķina sadalīšanu pie galda un analītiku 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 no POS neatkarīgs. Jauna POS savienotājs neskar virtuves plūsmu vai maksājumu pakalpojumu — tas izmanto UVS līgumu un automātiski iegūst maksājumus, daudzīrniecību un atskaites. R-Keeper ir viena šī līguma implementācija; 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 tīšām nav norādītas šajā publiskajā virsmā — partneri, kas veido POS savienotājus, saņem versiju piespraušanu 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.
• Karšu dati, atmaksas, 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 tiks piegādāti).
• Mārketinga teksts, publiskie dokumenti, AI asistents, MCP serveris → šī vietne.

Ja integrējaties ar Fooodo, jūs interesējošā API virsma ir izvēlnes lietotnes ārējais API. Maksājumu pakalpojums ir iekšējs — izvēlnes lietotne darbojas kā starpnieks uz to.