Kunden fragen, warum ihre Bestellseite schneller ist als die Marketplace-App, und deren IT fragt nach dem Rechenzentrum. Beide verdienen eine echte Antwort. Hier ist die hinter 300+ Standorten.
Zwei Fragen kommen in jedem Restaurant-Projekt — meist Wochen auseinander und von verschiedenen Leuten.
Der Inhaber fragt, warum sich das schneller anfühlt als die Marketplace-App. Sein IT-Kontakt — oder der IT-Kontakt der Gruppe, zu der er gehört — fragt, in welchem Rechenzentrum das läuft, ob ein AVV vorliegt und was passiert, wenn dieses Rechenzentrum ausfällt. Du brauchst für beides eine Antwort, die kurz und wahr ist und nicht zusammenbricht, sobald jemand technisch nachfragt.
Das ist diese Antwort — inklusive der Stellen, an denen sie ehrlich begrenzt ist.
Die meisten Bestellplattformen sind im Demo schnell und freitags um 19:30 langsam. Diese Lücke ist kein Durchsatz-Problem — ein einzelner mittelmäßiger Server verarbeitet das Bestellvolumen von hundert Restaurants ohne Mühe. Es ist Latenz, und Latenz verhält sich anders: Sie degradiert nicht sanft, sie summiert sich über Round-Trips, und sie trifft genau dort am härtesten, wo du es am wenigsten verkraftest — ein Gast auf dem Bürgersteig, am Handy, im Mobilfunknetz, der entscheidet, ob er weitertippt.
Nimm die langweilige Variante des Stacks: ein regionaler Ursprungsserver, eine Datenbank daneben, ein CDN davor für die statischen Assets. Ein Gast in Portugal bestellt bei einem Restaurant, dessen Plattform-Ursprung in Frankfurt steht.
Bevor ein einziges Byte Speisekarte erscheint, macht das Handy einen DNS-Lookup, einen TCP-Handshake und eine TLS-Verhandlung. Über Mobilfunk zu einem entfernten Ursprung ist jedes davon ein Round-Trip, TLS oft zwei. Sagen wir vier Round-Trips mit 60–80 ms, nur um das Gespräch zu eröffnen. Erst danach geht die Anfrage für die Seite raus, und der Ursprung muss die Speisekarte abfragen, rendern und antworten.
Das CDN erledigt Logo und CSS. Für den entscheidenden Teil tut es nichts, denn die Speisekarte ist nicht statisch — sie hängt davon ab, welches Restaurant, welche Öffnungszeiten, ob ein Gericht vor vier Minuten ausverkauft war. Das HTML ist ein Cache-Miss by Design, und jeder Cache-Miss ist eine volle Reise zurück nach Frankfurt.
Und dann kommt die Session obendrauf: ein Artikel hinzufügen, einen Coupon einlösen, eine Liefer-PLZ prüfen, zusehen, wie eine Bestellung von eingegangen auf in der Küche wechselt. Jedes davon ist eine weitere Reise zum selben entfernten Ursprung. Jede einzelne Zahl sieht im Monitoring-Dashboard vertretbar aus. Die Summe ist, was der Gast erlebt — und die Summe ist, wo Bestellungen abgebrochen werden.
Am Edge zu laufen heißt nicht „ein CDN davorstellen“. Es heißt, dass der Code, der den Storefront rendert, der Speicher, aus dem er liest, und die Session, in die er schreibt, alle nah beim Gast sind — statt nah beieinander in einer Region.
Praktisch: Das Storefront-HTML wird an dem der 300+ Standorte gerendert, der am nächsten liegt. Der Speisekarten-Lesezugriff kommt aus einem geo-replizierten Speicher statt von einem Primary in einer Region. Session und Idempotency-Keys liegen in einem Edge-Cache statt hinter dem Ursprung. Und Speisenfotos werden an demselben Standort nach AVIF oder WebP konvertiert, der sie ausliefert. Ein 2-MB-Foto, das der Inhaber direkt vom Handy hochgeladen hat, wird zu rund 30 KB, bevor es beim Gast ankommt — und es überquert keinen Kontinent, um verkleinert zu werden.
Das Aufsummieren arbeitet dann für dich. Jede Reise ist kurz, also fühlt sich die Interaktion unmittelbar an statt nur akzeptabel. Typische Storefront-Latenz landet unter 50 ms beim Gast — und, für dich nützlicher, sie landet dort, egal ob der Gast in Rottweil oder in São Paulo sitzt, weil es keine Heimatregion gibt, von der er weit weg sein könnte.
Das ist das Versprechen, das du geben kannst: kein Benchmark, sondern die Abwesenheit des schlechten Falls. Du behauptest keine Zahl, die nur für Gäste in der Nähe einer bestimmten Stadt gilt.
Sei bei den Grenzen deutlich, denn ein Kunde, der sie später selbst entdeckt, glaubt dir den Rest nicht mehr.
Schreibvorgänge brauchen weiterhin Koordination. Eine Bestellung aufzugeben ist kein Lesezugriff, den man von überall bedienen kann. Er muss dauerhaft sein und genau einmal passieren, und keine dieser Eigenschaften ergibt sich aus geografischer Nähe. Was der Edge beiträgt: Der Retry ist günstig. Idempotency-Keys nah beim Gast bedeuten, dass eine wackelige Verbindung, die mitten im Absenden abbricht, schnell aufgelöst wird — statt jemanden vor einem Spinner sitzen zu lassen, der überlegt, ob er nochmal drückt. Der Schreibvorgang bleibt ein Schreibvorgang.
Kalte Daten bleiben kalt. Ein Restaurant ohne Bestellung seit drei Tagen hat nirgendwo einen warmen Cache. Sein erster Gast am Morgen zahlt etwas mehr als sein hundertster.
Verteilung ist nicht Verfügbarkeit. An 300+ Standorten zu sein heißt nicht, dass nichts schiefgeht — es heißt, dass ein einzelner Standort, der ausfällt, kein Ausfall ist. Das sind verschiedene Aussagen, und sie zu vermischen ist der Weg zu einer Zahl, hinter der du nicht stehen kannst. Die Zusage lautet 99,9 % im Jahresmittel, mit Wartung außerhalb der Zeiten, in denen Restaurants tatsächlich Bestellungen annehmen — 12:00–14:00 und 18:00–22:00 Uhr MEZ. Nenne das, nicht „immer online“.
Die interessante Entscheidung war nicht „nutze den Edge“. Sie war, die Plattform nicht aus den Edges von vier Anbietern zusammenzusetzen.
Ein Runtime rendert den Storefront, führt die geplanten Jobs aus, treibt die Webhook-Pipeline und transformiert die Bilder. Ein Datenspeicher hält Speisekarte, Bestellungen und Konten. Ein Auth-System deckt den Magic-Link des Gastes und das Dashboard-Login des Managers ab. Nichts im Bestellpfad ist ein Netzwerk-Hop zum Produkt einer anderen Firma.
Das klingt nach einer ästhetischen Vorliebe, bis du es durchrechnest. Ein Stack, zusammengeklebt aus Hosting-Anbieter, verwalteter Datenbank in einer Region, Bild-CDN, Queue und WebSocket-Dienst, hat eine Kostenuntergrenze aus den Mindestbeträgen von fünf Anbietern — und jeder Hop ist eine Stelle, an der Latenz und Fehler dazukommen. Diese Hops einzusammeln ist der Grund, warum $20 pro Monat ein kohärenter Preis ist und kein Lockangebot — und warum dein elftes Restaurant fast nichts mehr kostet als dein zehntes.
Der praktische Effekt ist die Abwesenheit von Fragen.
Es gibt keine Region zu wählen im Onboarding, also muss niemand raten, ob die künftige Expansion eines Kunden in der falschen Hemisphäre landet. Die Zeile „welches Rechenzentrum“ im Beschaffungsformular hat eine ehrliche Ein-Satz-Antwort: in allen — und hier ist der AVV. Es gibt kein separates CDN-Konto, keinen Bilddienst, keinen WebSocket-Anbieter, den die IT deines Kunden prüfen muss, was die Security-Review von fünf Lieferanten auf einen verkürzt. Und wenn der Inhaber fragt, warum seine Seite schneller ist als die des Marketplace, passt die Antwort in einen Satz, den du ohne Ausweichen aussprechen kannst.
Nichts davon ist glamourös. Es ist überwiegend das Entfernen von Entscheidungen, die nie das Problem deines Kunden hätten sein sollen — und, wichtiger, nie deins zu verteidigen.
Sei unter den ersten Studios auf Margord. Keine Kreditkarte nötig.