#249 Resilience Engineering: Rate Limiting oder wie 429 dein System rettet

[SPEAKER_00]: Moin. [SPEAKER_00]: Du bist hier im Engineering Kirs gelandet und mein Name ist Andy, einer der Ko-Host dieses Podcasts. [SPEAKER_00]: Heute hab ich mir mal wieder ein Thema ausgesucht, es geht erneut um eins meiner Lieblingstämme, Reliability und Resilience Engineering. [SPEAKER_00]: Nachdem wir uns schon um Themen wie Timeouts, Jitter, Back-Off so wie Tail Latency und Request Hatching gekümmert haben, [SPEAKER_00]: Gibt es heute mal ein Deep Dive zum Thema Rade Limiting?

[SPEAKER_00]: Wir klären, wozu Rade Limiting da ist, was die Abkretzung zu begriffen, wie Backpressure, Graceful degradation, Fallout, Isolation und Load Shading ist.

[SPEAKER_00]: Wo Rade Limiting in deinem System beziehungsweise in deiner Echtektur verankert ist, welche Rade Limiting Strategien existieren, wie man adiert, [SPEAKER_00]: Wenn sogar der Rätlimeter ausfällt, warum Rätlimeter nicht nur eine Engineering, sondern auch eine Produktmanagementfrage ist, wie platformen, wie GitHub und Cloudflad den Kleinen über seine Rätlimeter informieren und warum Rätlimeter für GrafQL API ist ein schwierigs Unterfangenes.

[SPEAKER_00]: Eine ganze Menge Holz für eine Podcast-In-Pisote. [SPEAKER_00]: Das ist ja richtig. [SPEAKER_00]: Wir springen mal direkt rein. [SPEAKER_00]: Viel Spaß. [SPEAKER_01]: Wie du erweist an, die habe ich eben bei noch eines oder eigentlich recht viele kleine Start-up zum Laffen, aber einen ganz konkretes.

[SPEAKER_01]: Im Zuge von diesem Start-up war ich auch bei so einem Incubator, der lokalisiert ist in einem großen Gebäude, wo eine Berufsschule auch drinnen ist und so weiterbildungen und so weiter. [SPEAKER_01]: Und da ist es mir schon ein, zwei, drei Mal passiert, dass sie auf Google gehen wollte. [SPEAKER_01]: Und mit dann zu einem Capture entgegengewaufen wurde. [SPEAKER_01]: Es gab zu viele Request auf Google und ob ich wirklich ein Mensch bin.

[SPEAKER_01]: Wie oft hast einer Deiner Crawler schon mal irgendwie so was produziert, dass alle in dem gesamten Gebäude diese Website zugesicht bekommen, dass zu viele Requestes eingehen von dieser gleichen Appierdresse? [SPEAKER_00]: Ich meine, das ist ein klassisches Problem, wenn ich glaube, du einen Proxinum in einer Outgoing IP hast. [SPEAKER_00]: Also ich glaube, da musste gar kein Crawler am Laufen haben.

[SPEAKER_01]: Also mein Tipp ist schon, dass der Inking-Crawler im Hintergrund war und der wird ja auch viel Ausbildung gemacht, dem digitalen Bereich, dass der irgendwann kleinen Krawler geschrieben hat. [SPEAKER_01]: Aber wie viel Krawler hast du schon geschrieben und bist denn irgendwelche Rätlimi jetzt gelaufen? [SPEAKER_01]: Oder mit welchen, vielleicht anders gefragt mit welchen Krawler bist du nicht in einen Rätlimi gelaufen?

[SPEAKER_00]: In der Tat ist das eine Zerviecher, was ich wirklich sehr sehr früh in meine Kroller einbauhe. [SPEAKER_00]: Und deswegen bin ich immer sehr sehr glücklich, wenn die Services, die ich versuchen zu Krollen, dann mir wirklich die Rate-Limitinginformationen mitgeben. [SPEAKER_00]: Für schlimmer ist ja, wenn der Services nicht Krollen möchte genau so was macht, wie du gerade beschrieben hast, da gibt man einfach einen Kaptcher.

[SPEAKER_00]: Weil dann ist mein Kroller ohne irgendwie Headless UI oder ähnliches natürlich auch aufgeschmissen. [SPEAKER_00]: Sondern wenn ich die Rate-Limitinginformationen den schönen Maschinen lesbar zurückbekommen, dann weiß ich ja wenigstens was ich zu tun habe.

[SPEAKER_01]: Ich muss dazu geben, ich habe noch nie einen Radclimiting implementiert, sondern ich kann eigentlich nur den 429 hat, der die B-Status, den man zu zurückgeworfen, bekommt meistens zumindest, wenn man einfach zu viel Anfragen schickt. [SPEAKER_01]: Aber nachdem du ja meine Go-Tube, also Pan-Internet, Go-Tube, Person-Bist, wenn es um Death-Obs geht, oder dem ganzen Bereich der dahinter liegt, lasse ich mir von dir halt mal erklären, wie man Radclimiting.

[SPEAKER_01]: richtig implementiert und welche Möglichkeiten man hat, wenn man nicht auf der crawlerseite sitzt, sondern auf der developerseite sitzt. [SPEAKER_00]: Und meine es acht bis nach ist, dass gar kein Bereich von Def-Op-Beziehungsweise die Def-Ops-Räute die draußen im Markt so rumrennen, die wenigsten davon beschäftigen sich, glaube ich, so tief mit Red-Limiting, sondern

[SPEAKER_00]: Ich denke, er ist ein satellite-ability-engineering-tamer oder vielleicht sogar ein Software-Eichtig-Tour-Tamer und nicht ein DevOps-Tamer, aber das nur so am Rande genauso wie du jedes Deiner Schnaps-Edeen, was du als Start-up bezeichnest, das ist also auch unkommentiert, was soll zu Tage alles ins Start-up ist. [SPEAKER_01]: Ich schick dir dann das Feedback von meinem Co-Founder weiter.

[SPEAKER_01]: Aber, erklären wir mal, ich habe jetzt zum Beispiel bei einem meiner vielen Projekte. [SPEAKER_01]: Da läuft das Radly-Mitting so. [SPEAKER_01]: Das Service überlastet und wirft dann 500 der Fehler. [SPEAKER_01]: Ist das dann schon Radly-Mitting?

[SPEAKER_00]: Ja, das ist viel in das Radly-Mitting, genau. [SPEAKER_00]: Ich mein. [SPEAKER_00]: Rate Limiting ist ja die Frage, warum braucht man das überhaupt und eine primäre Sinn von Rate Limiting ist halt genau, die Überlastung eines Systemes zu verhindern.

[SPEAKER_00]: Meine Systeme scheitern selten an eine Request, sondern in der Regel an zufielen, wie zum Beispiel irgendwie kleine Bucks, Retry Storms oder Traffic Spikes und Rate Limiting kannst du dir so als ja, wie soll ich sagen, als sicherheitsgut vorstellen. [SPEAKER_01]: Jetzt damit so fremdwort dann herumwaffen und muss die schon erklären auch Retriestürmen, Traffix Bikes. [SPEAKER_01]: Da die das.

[SPEAKER_00]: Machen wir mal, dass dann exkurs zu typischen Fail-Jermodes. [SPEAKER_00]: Ja, Retriestürmen sind eigentlich viel geschlagenen Requests, die dann erneut abgefeuert werden. [SPEAKER_01]: Also genau das mit dem 500er Status-Code, wenn der Kleintanz sagt, dann probiert es nochmal und nochmal und nochmal. [SPEAKER_00]: Ja, das ist unverschämtisch Retri. [SPEAKER_00]: Das meine ich nicht, ich meinte eher.

[SPEAKER_00]: Du bist mit deinem Handy unterwegs, fährst durch ein Tunnel, bevor du in Tunnel reingefahren bist, sind es gerade noch ein Riequest, im Tunnel verlierst du die Konnexchen, kurz um der Riequest kam gar nicht richtig durch, fährst aus im Tunnel wieder raus, kriegst wir dann Netz und machst dann wieder ein Riequest.

[SPEAKER_00]: Und wenn du dann mit einem vielleicht sehr großen Zug, [SPEAKER_00]: Durch den Tunnel fährst, wo tausende Leute gerade surfen und alle auf dieser Webseite gehen, dann kann das sein, dass alle nach dem Tunnel ein Retri-Machen und tun mit ein Retri-Sturm auslöst. [SPEAKER_00]: Was dann natürlich sehr viele Regmas auf einmal auf den Service hätten, sehr unverscheinig, dass das jetzt in einer Zug verpasiert.

[SPEAKER_00]: Dann geht es auf der anderen Seite noch ein Thundering-Hurtproblem, das bedeutet zum Beispiel das ziemlich viele Kleins, auf das gleiche Event reagieren.

[SPEAKER_00]: Oder auf das selbe Ereignis gleichzeitig reagieren. [SPEAKER_00]: Beispiel du hast sehr viele Server, aber die greifen alle auf ein Cash-Kie zu, dieser Cash-Kie expiert und all diese Server gehen dann automatisch auf die Datenbank. [SPEAKER_00]: Das wäre so ein Thundering-Hurtproblem.

[SPEAKER_01]: Darüber haben wir übrigens auch schon in Episode 2 und 4 gesprochen, wo es um Timeout's Gitterbackhoff gegangen ist, wo wir genau das Vorgehen beschreiben, wie man solche Dinge verhindern kann, wenn die Kleins intelligent agieren und nicht sofort immer Re-Trice raussenden.

[SPEAKER_01]: Oder wenn Re-Quest ganz allgemein irgendwo langsamer sind oder nicht funktionieren, dass man dann eben Vollgas gibt, sondern ganz im Gegenteil sich zurücknimmt und dann eben zum Beispiel eine Timeout. [SPEAKER_01]: Abwartet oder Zufallswert noch mit dazu gibt für den Timeout. [SPEAKER_01]: Kann man alles in Episode 2 oder 4 nachhören oder an die sich damals ausgelassen hat, um den ganzen Bereich auf der Kleinen Seite?

[SPEAKER_00]: Ich mein, du kannst ja auch selbst ins Knie schießen und das passiert sehr oft besonders in so Microsoft, sehr eichlebt worden, sind sich Traffic Amplification oder Fan-Out-Service. [SPEAKER_00]: dass wenn ein Microsoft-Service dann 5 oder 8 oder 10 Request in deinem Microsoft-Servis echtektur macht. [SPEAKER_00]: Und wenn du dann einfach vorne auf dem ersten Microsoft-Servis in konstant er 5 konstant reload machst, dann hast du hinten raus in der Treffek-Emplifikation.

[SPEAKER_00]: Weil das halt einfach eine Modipulation nach Request ist, er und so mit, kannst du die halt sag mal selbst ins Knie schießen. [SPEAKER_00]: Nach einer Thema hat man vielleicht auch schon mal gehört, dass auch, ich hab'm Kölbefehl abgefeuert und der hat leider einen Low-Test gestartet, oder so, ne? [SPEAKER_00]: So den unbeabsichtigte Überlast, passiert ja auch ab und zu mal.

[SPEAKER_00]: Oder vielleicht hast du einfach nur ein Kunden oder ein Tenent, der einfach unverhältnischmäßig viele Ressourcen verbraucht, warum auch immer vielleicht seine Datenbank sehr groß oder der hat eine sehr teurer Operation am Loft. [SPEAKER_00]: Ja, das sind so die klassischen Failure Mode, Sunderinghood, Retry-Stürmer, Traffic-Emplifikation. [SPEAKER_00]: Eine unbeabsichtigte Überlastung. [SPEAKER_00]: Oder vielleicht auch eine barbsichtigte?

[SPEAKER_00]: Ja, die würde den in Love Service Attacken gehören da auch zu. [SPEAKER_00]: Imlich viele Firmen haben auch immer so ein Boyd-Batch-Job, der jeder zu jeder vollen Stunde startet. [SPEAKER_00]: Das ist auch so ein Klassiker, dass der Batch-Job immer so Spikes in irgendwelchen Grafen erzeugt und es auch mal achter, ist ja wieder der Batch-Job. [SPEAKER_00]: Hast du vielleicht auch schon mal gesehen? [SPEAKER_00]: Gut, das ist mal nicht da, Regenvorrags gesetzt.

[SPEAKER_00]: Ja, oder von mir aus auch einfach jede Stunde Kunden, die anrufen, weil das Service langsam ist. [SPEAKER_00]: Oder ich überhaupt ausfällt, ja, genau. [SPEAKER_00]: Ja, man im Kunde ist immer das beste Monitoring.

[SPEAKER_00]: Norma zusammengefasst, im Endeffekt Radlementing ist halt jetzt nicht nur in Simpler API Schutz, sondern hoffentlich eine systematische Lastbegrenzung von einem Service, das sein Service halt gerade keine 500er liefert, das Ziel ist halt, der Schutz des Services und nicht die Bestrafung der Kleins. [SPEAKER_01]: Und meine Meinung sehen wir da jetzt eine schon bei einer Key-Ausage von dieser Episode.

[SPEAKER_01]: Weil ich vermute mal, dass die wenigsten sich überhaupt Gedanken machen über dieses Problem. [SPEAKER_01]: Dass man überhaupt einmal an diesen Punkt kommt, okay, wie kann ich denn einen Schutz da einziehen? [SPEAKER_01]: Eine Barriere einziehen, die im Falle irgendwie greift.

[SPEAKER_01]: Und man glaubt das gar nicht wie schnell so was eigentlich ... [SPEAKER_01]: Demer werden kann, also bei unserer Botkast-Blatform, z.B. [SPEAKER_01]: von unserer Analyse-Blatform-Obotkast, da haben wir sehr wenig Request, aber die Request triggeren sehr komplexe Anfragen im Hintergrund auf der Datenbank.

[SPEAKER_01]: Und da macht's eigentlich schon Sinn, Redlihmittingen zu haben oder sich zumindest zu überlegen, wie könnte man so was strukturieren und einbauen, [SPEAKER_01]: Wohl man nur sehr wenige Request hat. [SPEAKER_01]: Also wir sprechen da gar nicht nur über irgendwelche Ablikationen, die Millionen von Request haben, sondern es können auch wesentlich kleinere Ablikationen sein.

[SPEAKER_01]: Und wenn man mal auf der Architekturseite sich überab mit dem dem dem Arsonand ersetzt, macht es sich ja absolut Sinn ohne, dass man jetzt schon mal in die Implementierungserkläringe, da war einfach sich zu überlegen, wie sieht man da in den Schutz ein oder hat man den Schutz in irgendeiner Form überhaupt? [SPEAKER_00]: Dabei muss man sagen, dass den Wolfgang bei seiner Home Podcast platform aber auch so ein bisschen Monitoring fehlt.

[SPEAKER_00]: Denn ich hab mal für einen Engineering Cures, diese platform genutzt, hab die API angesprochen, um die Top 10, der Best-Off-Episodeen vom Engineering Cures, kontinuierlich zu ziehen. [SPEAKER_00]: Und immer wenn ich den API request absende, kriege ich halt so in 50, 60, 70 Prozent der Fälle halt so in 500 hat zurück, weil, weiß ich nicht, wahrscheinlich irgendein Engine X, die Connection vorher dicht macht, bevor die Respons von der Datenbank kommt.

[SPEAKER_00]: Der Wolfgang sagt dann immer, ich sehe hier kein Fehler. [SPEAKER_00]: Und dann probete das selbst nochmal. [SPEAKER_00]: Und natürlich hat er von deinem Kölfe fehlt, dann irgendwie Timeout von 90. [SPEAKER_00]: Sie sind Kunden oder sowas. [SPEAKER_00]: Und dann ist es irgendwie ein Cash. [SPEAKER_00]: Und ich komme halt immer mit einem kalten Cash an. [SPEAKER_00]: Aber nun gut, ich bin mir aber nicht sicher, ob da Radel mit dem hilft.

[SPEAKER_00]: Und dann ob es dann nicht eher was anderes ist. [SPEAKER_00]: Und da kommen wir ja nämlich das Gleichzuste der Abkrenzung oder zu einem anderen X-Kurs. [SPEAKER_00]: Was ist nämlich neben dem Radel mit dem Ding noch so gibt, was ihr vielleicht doch eher implementieren soll. [SPEAKER_00]: Dann schieß mal los. [SPEAKER_00]: Ja, also im Endeffekt habe ich ja gerade gesagt, ich sende einen Request und kriegte 500 davon dann der Plattform zurück.

[SPEAKER_00]: Und ich hoffe, du willst jetzt nicht meinen einen Request-Ratel mit den, oder? [SPEAKER_01]: Wenn du so die bösen Anfragen trägerst, vielleicht schon, vielleicht sollt bei deiner Ratel mit auf Nullsetzen dann. [SPEAKER_00]: In den ganzen Kontext von Rade, Limitting und seine API schützen oder Beziehungsphase, das System mit einer Lastbegrenzung zu versehen, schwirren noch so ein paar andere Begriffe rum. [SPEAKER_00]: Ein Begriff ist zum Beispiel Backpicker.

[SPEAKER_00]: Ich habe mal glaube ich auch schon mal vorher erwähnt, da geht es eher darum, dass ein Überlassert der Teil des Systems nach oben signalisiert, haben wir jetzt gerade nicht gut. [SPEAKER_00]: Ich kann nicht mehr so viel verarbeiten, einfach gesagt, dass Downstream System, sagt dem Upstream System, bitte langsamer, ich komme nicht hinterher.

[SPEAKER_00]: Technisch bedeutet, dass in der Regel Q sind irgendwie voll Rights werden blockiert oder dein Downstream Microservice, sendet halt einfach ein 400.9.20er, hat der DPS start aus Call oder bei G-Arpiseen Resource Exhaustet oder ähnliches. [SPEAKER_01]: Und bei das ja eigentlich dann schon rate limitig wäre, oder? [SPEAKER_01]: Wenn ich so wenn signalsehende, wenn die Rate überschritten ist. [SPEAKER_00]: Ja, nein.

[SPEAKER_00]: Du kannst Backpressure als eine Art Radelmitting sehen, aber Backpressure ist reaktiv und entsteht zur Laufzeit und nicht durch eine Polizie. [SPEAKER_00]: Die Einordnung von Radelmit zu Backpressure ist, dass Radelmitting ist eine explizite und frühzeitige Form von Backpressure.

[SPEAKER_00]: Der Unterschiede sagt, Backpressure, ich bin überlastet und Radelmitting sagt, du darfst nicht mehr als X. [SPEAKER_00]: Du kannst ja so eigentlich sagen, Radelmitting ist Backpressure mit Vertrag und Zahlen. [SPEAKER_00]: Wo hingegen, wenn Backpusher Triggerad ist das System bereits schon überlastet.

[SPEAKER_01]: Also im Idealfall, wenn ihr Redli-Mitting haben, was sauber funktioniert, dann brauche ich gar keinen Backpusher aus senten im Idealfall, weil das System gar nicht zu dem Punkt kommt, dass es überlastet ist. [SPEAKER_00]: So fern die Schwellenwerte für das Redli-Mitting gut gewählt sind ja. [SPEAKER_00]: Du kannst natürlich Backperger immer noch als Sicherheitssetz und unterhaben. [SPEAKER_00]: Also Sicherheitsnetze kannst du natürlich fünfmal haben, sammst.

[SPEAKER_01]: Ganz allgemein mag ich, man kann sich wahrscheinlich nicht auf straight limiting verlassen, weil man muss ja trotzdem irgendwie monitorn und man kann ja trotzdem in den Zustand kommen, wo man einfach überlastet ist, als was wir im Grunde auch immer. [SPEAKER_01]: Also es ist einiglichst an, reinig das. [SPEAKER_00]: Genau. [SPEAKER_00]: Nandere tematik ist graceful degradation.

[SPEAKER_00]: Das bedeutet eigentlich, dass wenn dein System last hat oder du weißt, es kommt last, dass du manze Funktionalität einfach ausschalten. [SPEAKER_00]: Ich hatte das mal erzählt, wenn ich mir karten für die Totenhosenkaufe. [SPEAKER_00]: Dann kann ich mich in dem Shop einloggen? [SPEAKER_00]: Bingo, Bingo, ihr habt acht Striche von Totenhosen verkauft. [SPEAKER_00]: Dann kann ich aber nicht mehr mir meine letzten Bestellungen anzeigen lassen.

[SPEAKER_00]: Während des Karten vor Verkaufs deaktiviert, der Shop diese Funktionalität. [SPEAKER_00]: Und das ist eine, ich sag mal, manuelle proaktive Graceful degradation. [SPEAKER_00]: Die sagt halt, okay, unterlast oder bei Fehlern liefer ich weniger Features anstatt komplett auszufallen. [SPEAKER_00]: Die sagen halt so einfach lieber eingeschränkt funktionieren als gar nicht.

[SPEAKER_00]: Was glaube ich ganz gut ist, denn die meisten Leute wollen halt Konzertkarten kaufen und nicht gucken, wann sie das letztes Jahr ihr T-Shirt bestellt habt. [SPEAKER_01]: Das heißt, übersetzt in deinem Beispiel, wenn du bei OpenBotcast die Anfrage gestartet hast, gibt mit die zehn erfolgreichsten Episoden und das eine sehr langsamer Anfrage ist, dass ich genau diese langsamen Anfragen vielleicht blockiere und die schnellen Anfragen aber weiterhin ausliefer.

[SPEAKER_00]: Also das ist ein relativ schlechtes Beispiel, weil ich ja nur ein API-Request für eine sehr teurer Operation sind. [SPEAKER_00]: Wenn du aber im Deine System merkst, dass dieser eine Request sehr höhere Operation hat und du es nicht schaffst, mit die kompletten Daten zu geben, dann kann zu sagen, okay, ich mache eine Graceful Degradation und geben mir eine geringere Datenqualität zurück, anstatt das volle Result hat. [SPEAKER_00]: Das wäre auch eine Form von Graceful Degradation.

[SPEAKER_00]: Beispiel Features Abschalten, geringere Datenqualität liefern, [SPEAKER_00]: Du lief hast zum Beispiel in altes Ergebnisse aus, also in Cash an Stadleif da, oder du schaltest etwas nur im Read Only Modus, ja, zum Beispiel, jetzt bei deiner Home platform, ich glaube, da kann ich gar nicht über die API schreiben. [SPEAKER_00]: Ja, dein Mantra ist halt einfach, okay, ich funkt zu nieere immer noch, aber dann halt nicht mehr vollen Service.

[SPEAKER_00]: Und im Endeffekt ist es, wie im richtigen Leben, ja, also wenn du im richtigen Leben immer nur ja sagst, [SPEAKER_00]: Und nie nein, ja, viele Leute sagen ja, deine richtige Power ist auch neue Nein zu sagen und so weiter. [SPEAKER_00]: Und das ist bei Produktmanagement und bei Systemen und bei Plattformen ja genauso graceful degradation funktioniert nur, wenn wir bewusst nein sagen können zu gewissen Features.

[SPEAKER_00]: Also dafür muss ich natürlich auch Gedanken machen, welches Feature ist denn bei dir wichtiger als das andere. [SPEAKER_00]: Und frag das meine Produktmanager und der wird sagen, alles ist wichtig. [SPEAKER_01]: another im Punkt, der dann auch damit zusammenhängt, ist die Fault isolation.

[SPEAKER_01]: Also wenn es dann wirklich so weit ist, dass es dann wirklich ein Problem gibt, weil wenn es z.B. [SPEAKER_01]: ein neues Neben gibt, also einen Tenent einen Kunden zu beispielsweise der super viele Anfragen sendet, dann will man natürlich nicht das ganze System killen oder daunhaben, sondern den eigentlichen Verursacher irgendwie aus dem System herausnehmen.

[SPEAKER_01]: Da haben wir auch eine ganze Episodes zugemacht mit dem Max-Shellhorn von AWS über Multitänent, [SPEAKER_01]: Organisation, Isolationsmodelle und Ähnliches kann man gerne mal reinhören, Episode 212, wo wir genau darüber gesprochen haben, was macht man, wenn ein Kunde verrückt spielt oder ein Kunde angegriffen wird und wie kann man das System am Leben erhalten und dem restlichen Kunden den guten Kunden unter Anführungszeichen weiterhin Datencenten und diese Bedienen?

[SPEAKER_00]: Ja, da ist halt so der Merk Satz, okay, wenn was kaputt geht, also wenn es unvermeitlich ist, aber dann ein bisschen nur dort drüben. [SPEAKER_00]: Beim Nachbarn, beim Neucheneber, wenn was kaputt geht, dann beim Nachbarn. [SPEAKER_00]: Ja, es bedeutet halt eigentlich vieler bleiben Lokal und reißen nicht das ganze System runter. [SPEAKER_00]: Du merkst halt schon, ne? [SPEAKER_00]: Wir sprechen die ganze Zeit immer nur über den Worstcase.

[SPEAKER_00]: Wir sind ja schon im Schadensmodus. [SPEAKER_00]: Also dann ist die Frage, wie groß ist der Schaden? [SPEAKER_01]: Gut, aber jetzt haben wir ganz viele Sachen besprochen, die eigentlich gar nichts, direkt mit Radlimiting zu tun haben, bzw. [SPEAKER_01]: nur in dem Dunstkreis mit dabei sind. [SPEAKER_00]: Also, das kannst du nicht so sagen, weil im Endeffekt Radlimiting ist ja einer der effektivsten Mittel zu erfolgt, isolationation zu beispielsweise.

[SPEAKER_00]: Du kannst ja beim Radlimiting pro Kunde oder pro Tenent dynamisch fahren. [SPEAKER_00]: Ich will nur sagen, das sind alles begriffel, vold isolation graceful degradation and back pressure, die halt an ihnen am ganzen Dunzkrass immer da reinkommen, aber es ist halt nicht rate limitiger. [SPEAKER_00]: Das sind halt irgendwie unterformen oder rate limiting ermöglicht, also bei ihm.

[SPEAKER_01]: Genau, du wirst es meine tolle Überleitung zerstört, die weil die Wollte ja überleiten, dass wir das alles verhindern können, mit einem richtigen rate limiting im System. [SPEAKER_01]: Und das war jetzt dein Stichwort gewesen, an die um rate limiting zu erklären und tieferen zu gehen. [SPEAKER_01]: Da stelle ich mal die erste Frage an dich architect Wolfgang. [SPEAKER_00]: Jetzt lege dir da eine Überleitung und du kommst mit einer Frage an, das ist wieder typisch.

[SPEAKER_00]: Du kannst mir nicht das Wort geben, bei dem Thema geben wir uns mal im Monolog. [SPEAKER_00]: Wo platzierst du den Rathel-Mitting in deinem System? [SPEAKER_01]: Er schön ist ja, dass wir ein Gedaltes Notes dokument haben, wo jetzt einfach die Antwort runterlesen kann, weil da steht schön, Rathel-Mitting zu früh wie möglich, aber so nah wie nötig. [SPEAKER_00]: Siehst du das immer im Backhand oder sagst du Rathel-Mitting im Frontend, also im Kleint, macht auch irgendwie einen Sinn.

[SPEAKER_00]: Fangen wir mal vorne an, fangen wir mal im Kleinen an. [SPEAKER_01]: Beim so früh wie möglich ist, wäre dann auf der Kleinenseite. [SPEAKER_01]: Macht das Sinn für dich? [SPEAKER_01]: Wenn es ein guter Kleint ist, wir hatten hier schon die bösen und die guten Kleinsheit. [SPEAKER_01]: Wenn ein Kleint sich sauber verhält und richtig damit umgeht, ist es natürlich als beste, wenn der Kleint auch schon das Rate limiting macht.

[SPEAKER_01]: Es wäre der Klassiker nicht bei einem Crawler. [SPEAKER_01]: Wenn du weißt, du hast dann Rate limiting, dann stellst du den Crawler schon. [SPEAKER_01]: weiter nach unten, dass der irgendwelche Bausend zwischen drin hat, zwischen den Request um das eigentliches System nicht zu belasten.

[SPEAKER_01]: Also es ist natürlich möglich, auf der Kleinzeite, das große Problem, auf der Kleinzeite ist, du als Server, als Anbiet, als Blattform, hast du dich keinen Einfluss auf die Kleinst, du kannst zu hoffen, dass der Kleint nett ist, aber zwingend kannst du den Kleint nicht nett zu sein.

[SPEAKER_01]: Hast du den schon mal netten kleinen Implementiert? [SPEAKER_01]: Bist du den schon mal? [SPEAKER_01]: Ja, jeder meiner Krawler ist nett. [SPEAKER_01]: Weil sonst würden sie ständig in Rettling mit den laufen. [SPEAKER_01]: Darum sind alle meine Krawler in unten vom net. [SPEAKER_01]: Aber meistens natürlich ganz knapp an dem Rettling mit den. [SPEAKER_01]: Weil man will ja möglichst viele Request bekommen. [SPEAKER_01]: Aber nicht irgendwie geblockt werden.

[SPEAKER_01]: Oder einen Rettling mit den kleinen Laufen. [SPEAKER_00]: Ja, ich rede jetzt nicht nur von meinen Krawler. [SPEAKER_00]: Ich rede jetzt nicht nur von meinen Krawler. [SPEAKER_00]: Ich rede jetzt nicht nur von meinen Krawler. [SPEAKER_00]: Ich rede jetzt nicht von meinen Krawler. [SPEAKER_00]: Wirklich Funktionalität hat die auf Basis der HTP Responsecoats unterschiedlich agiert. [SPEAKER_01]: Also wirklich die Responsecoats respektiert möchte ich versagen.

[SPEAKER_01]: Landet und einfach basic-kunden-Bartet oder so was, das ist eigentlich schon fast standard und versuche schon eigentlich überall zu implementieren, wo wirklich mehrere Rick West auch Sende. [SPEAKER_01]: Was ihr auch oft macht, ist einfach möglichst nett zu sein.

[SPEAKER_01]: Vor allem, wenn ich selber und klein programmiere, dann mache ich das ihr wirklicherweise, dass wenn der klein mehrere Rick West senden würde, zum Beispiel, wenn man eine Suche implementiert und [SPEAKER_01]: Dass man diese zusammenfasst und wartet, okay, hat er zusätzlich 500 Millisekunden eine Bausage gemacht, keinen neuen Buchstaben eingegeben und das dann sende es du den Search Quick West zum Beispiel.

[SPEAKER_01]: Also solche Dinge pro Gramierüblicherweise schon um einfach den Server bisschen zu entlasten und wie gesagt, ob ich erweise bin, ich auch das Server die Wellebar und dann entlast ich mich selber. [SPEAKER_01]: Also so kleinekeiten kann man eigentlich relativ einfach implementieren und das denke üblicherweise schon mit dir.

[SPEAKER_00]: Schönes Beispiel dieser Auto komplett vom Formularer, aber ja in der Tat, das ist so ein dunkles Klassiker, wo wirklich Leute mit Request um sich haben, aber ein anderes Beispiel ist halt auch, wenn du ein offline-Funktionität oder ein flakey network hast, dass du einfach deine Request danach cute und langsam oder beziehungsweise kontrolliert abfeuert, wenn du wieder Netzwerk konnektivität hast, anstatt alles sofort, nach dem Reconnect zu folgern.

[SPEAKER_00]: Aber im Endeffekt, [SPEAKER_00]: Wir haben jetzt ein paar Sachen durchgesprochen und da kommt schon recht komplexer Kleinen zustande, auf wie viel Sachen du da achten musst. [SPEAKER_00]: Aber wie du auch schon sagtest, du kannst es halt nicht durchsetzen, als Backend. [SPEAKER_00]: Du hast keine Handhabe über die Kleins.

[SPEAKER_00]: In der Regel hast du in konsistente Implementierung und vielleicht in verschiedenen Programmier sprachen, die komplexität hat dich gerade angesprochen. [SPEAKER_00]: Und Achtung ein einziger Kleint und das wird viel Leuten gar nicht bewusst. [SPEAKER_00]: Der kennt ja gar nicht die globale Sicht. [SPEAKER_00]: Ich weiß ja gar nicht, ob du meinen Web-Service zum Beispiel von deinem Desktop-Computer und von meinem Handy und von noch einem iPad oder so benutzt.

[SPEAKER_00]: Also das bedeutet mehrere Geräte pro User Parallel-Sessions. [SPEAKER_00]: Vielleicht sogar eine unser obere Uhrzeit auf den Kleint. [SPEAKER_00]: Das kann schon eigentlich der Fehler sein, wann week west wie abgefäuert werden. [SPEAKER_01]: Ganz grundsätzlich, auch wenn man nette Kleint hat, Fehler gibt es immer und überall. [SPEAKER_01]: Und die kann man nicht ausschließen und auch einen netter Kleint kann mal vorückspielen. [SPEAKER_01]: Also was wir im Grunde auch immer.

[SPEAKER_00]: Es gibt aber auch eine Form von Daten, da kann der Kleint richtig net sein. [SPEAKER_00]: Und zwar gehen wir jetzt mal auf, dass Konzept vom Sampling. [SPEAKER_00]: Stell dir mal vor, der Kleint kriegt das Signal, dass das Beckend irgendwie belastet ist oder Great Limited wird oder halt irgendein Signal, entweder in 420 oder du rennsgraden Radel mit dem oder in.

[SPEAKER_00]: dann kannst du für manche Arten von Daten zum Beispiel für Telemetrydaten, für Analytics Daten, für Logging, Tracing und so weiter kannst du auch einfach deine Daten sampeln. [SPEAKER_00]: Dort, wo du eigentlich 10.000 Events senden würdest und vielleicht einfach 10.000 Request. [SPEAKER_01]: Also mit Logging Mindst du es, dass der Kleint lock sendet an irgendein Bekennt zum Beispiel. [SPEAKER_00]: Ja, Locks oder Telemetrydaten war era-reporting wie a century oder irgendwas, ja.

[SPEAKER_00]: Halt Daten, wo es nicht auf jeden einzelnen Request an kommt. [SPEAKER_00]: So man, ich sag mal, Daten, die du über Zeit kollektest, von mir aus auch User Telemetrydaten. [UNKNOWN]: Ja, so. [SPEAKER_00]: Dann kannst du sagen im Kleint, ich treffe jetzt die Entscheidung und sende nur 1 Prozent der Daten, die ich normalerweise sind würde, anstatt gar keine.

[SPEAKER_00]: Da durchverdiert, vor allem schon ein bisschen, ich sag mal den Detailgrad und so, weil du ja nun eine repräsentive Teilmänge sendes, aber du sendes wenigstens etwas. [SPEAKER_00]: Leute im Datnernologics-Bereich werden das kennen, weil besonders Leute im Big Data-Bereich, die werden ziemlich viel mit Sampling unterwegs sein. [SPEAKER_00]: Und wenn du zum Beispiel die Plattform Sentry nutzt, es ist eine Errol-Porting-Plattform, dort kannst du auch Sampling im Kleinen einstellen.

[SPEAKER_00]: Sende bitte nur so und so viel Prozent meines Errot-Traffix oder ähnliches. [SPEAKER_01]: Das muss dann aber der man speichentliches Backhand unterstützen, oder?

[SPEAKER_01]: Weil die muss ja mehr irgendwie sagen, das ist repräsentiert jetzt 100 Request, [SPEAKER_00]: Also ja, so weit kannst du natürlich auch gehen, aber im Endeffekt wäre das ja nur eine zweiter Intage oder ähnliches, die du in dem selben Rieck was mitzumachen, finde ich in eine nette Idee, musst du aber auch nicht. [SPEAKER_00]: Weil im Endeffekt kommt es halt ganz auf deine Daten und was das ist. [SPEAKER_01]: Okay, jetzt hast du mich in diesen Kleint gedrückt.

[SPEAKER_01]: Am Anfang, wenn wir jetzt zurückkommen zu deinem Spruch, denn du mir da in die Nutz geschrieben hast, rate limitierung so früh wie möglich, aber so nah wie nötig. [SPEAKER_01]: Was ist denn jetzt so nah wie nötig? [SPEAKER_01]: Also gehen wir mal davon aus, wir haben zwar netten Kleint, aber wir müssen da trotzdem irgendwie die Kontrolle behalten, wo macht jetzt rate limiting Sinn? [SPEAKER_01]: Mache das irgendwo, am Gateway machen es ganz hinten in der Datenbank, was macht Sinn?

[SPEAKER_00]: Ich könnte was sagen, um so mehr Rate-Limiting ebenn und du hast, desto sicherer bist du, aber das steigt natürlich auch dein Komplexitätsleverer in der Infrastruktur. [SPEAKER_00]: Wenn mir die Kleinen mal verlassen, dann geht der Request durchs Internet. [SPEAKER_00]: Und wenn nun weltweit das Netzwerk hast oder vielleicht nutzt du auch einfach nur und CDN oder ähnliches, dann bieten diese Services meist, irgendwann ab von Edge Computing.

[SPEAKER_00]: Was hat geografisch sehr nahe bei dir es? [SPEAKER_00]: Da kannst du halt z.B. [SPEAKER_00]: den ersten Radel-Mitting-Layer-Hin-Bang. [SPEAKER_00]: Edge Computing oder von mir aus auch eigene API-Gateway. [SPEAKER_00]: Ich sag mal die Eingangstür. [SPEAKER_00]: Bei AWS gibt es so was bei Google gibt es so was alles auch. [SPEAKER_00]: Von dem Edge Computing oder von einer Server-List-Funktion oder wo auch immer kann so natürlich dann direkt vor deinem Service oder bzw.

[SPEAKER_00]: Indeiner Service zu Service-Communikationen dazwischen kannst du. [SPEAKER_00]: Und rate limitting setzen. [SPEAKER_00]: Das machen mal viele Leute mit Hüben, so einem Side-Kar-Nend-Mann-Lass-Jahr, so einem En-Vol-Prox-Yoder-Lot-Bellen-Zerdats-Vischen, da implementiert man auch sehr oft eine Art von rate limitting. [SPEAKER_00]: Oder halt dann natürlich auch pro Ressorse, das bedeutet Pro-Datenbank, Pro-Q, Pro-Sert per RTAPI und so weiter.

[SPEAKER_00]: Das kannst du halt in die Dachdecker, kannst du machen, wie du möchtest. [SPEAKER_01]: Ok, jetzt haben wir jetzt entschieden, da überall Rettling mit den einzubaren, was mache denn jetzt wenn Rettling mit den. [SPEAKER_01]: Also mache das pro IP, da ist ja pro Kunde, bei mir eine eigene Struktur, was macht denn das Sinn und wie kann ich das herausfinden?

[SPEAKER_00]: Am liebsten hätte ich jetzt sogar einen so weitworten, dass er tolle Frage, an einem Endeffekt kannst du da so ein decision-tree mitbauen, weil du hast und ein paar Engineering fragen, die du vorher beantworten möchtest. [SPEAKER_00]: oder beziehungsweise sollte es erstes, dann redelmitting, möchte es du Request bursts erlauben oder nicht.

[SPEAKER_00]: Das bedeutet, es gibt kleines, die wenn die Hochfahren z.B. [SPEAKER_00]: sehr viele Mobile Apps machen das, die fahren hoch, feuern sechs Request raus und wenn die App oben ist, dann länd ihn nur ein Request pro Minute oder ihn. [SPEAKER_00]: Wenn die App geschatet wird, dann ist du also fünf, du hast einen kleinen Request burst und dann fällt das halt zu ab. [SPEAKER_00]: möchtest du Börs unterstützen oder nicht und respektieren oder nicht.

[SPEAKER_00]: Dann möchtest du einen Fähren rate limiting Algorithmus oder möchtest du einen einfachen rate limiting Algorithmus, kommen wir gleich zu und das dritte und das ist wohl meinst du achtenes nach, die wichtigste Frage möchtest du ein state full rate limiting Algorithmus oder ein state less rate limiting Algorithmus.

[SPEAKER_00]: Was ist jetzt Stateless und Statful? [SPEAKER_00]: Da ist eigentlich die Kiefrage, muss sich der Rätelimeter an die vergangenen Riequesse erinnern oder nicht. [SPEAKER_00]: Das bedeutet Stateless, es kommt ein Riequesse rein, kann die Entscheidung nur auf Basis dieses Riequesse getroffen werden. [SPEAKER_00]: Ohne sich an vorherige Riequesse zu erinnern. [SPEAKER_00]: Das ist Stateless.

[SPEAKER_01]: Also, da ein Beispiel, weil die muss ja immer irgendwie was wissen, oder wie viele Riequests reingekommen sind von dem Kunden zum Beispiel. [SPEAKER_00]: Na ja, du kannst ja schnell eine Holristikene abfäuern, ne? [SPEAKER_00]: Beispiel, wenn der User Agent nicht mit der Source IP zusammenhängt, dann kann sehne sofort ablehnen. [SPEAKER_00]: Das kannst ja aus diesem Request lesen.

[SPEAKER_00]: Viele ZDNs machen sowas, halt überall, wo Performance wirklich kritisch ist und die Weltververteilt sind. [SPEAKER_00]: Weil immer wenn du sehr schnell anworten muss, ist jeder Lookup halt super teuer. [SPEAKER_00]: Und die zweite Problematik ist, wenn dein CDN weltweit verteilt ist,

[SPEAKER_00]: Du brauchst ja irgendwo da ein Storage Zentral, damit du den vorherigen Request analysieren kannst und da eine Verbindung ziehen kannst und du weißt das selbst, wenn du eine Datenbank hast, die weltweit zugänglich ist, dann musst du halt irgendwie mal ein paar Millisekunden verlieren, um die Datenbank abzufragen und da geht die Performance an wieder runter, deswegen ziemlich viele CDN oder Edge Computing Networks, die Radling mithing haben, nutzen so ein Städlas Logik.

[SPEAKER_01]: Also Stateless heißt in dem Fall, ich habe keinen geschärten Stat über mehrere Instanzen in der Wecker war auf meiner Lokalen Instanze, habe ich dann schon mit einem Counter z.B. [SPEAKER_01]: wie viele Requests überhaupt reinkommen oder so was. [SPEAKER_00]: Du hast halt irgendwas, was anhand der Anzahl der Requests kein Speicherwachstum hat. [SPEAKER_00]: Was die Lokalen entscheiden kann, prinzipiell.

[SPEAKER_00]: Genau, und das ist auch schon der Nachteil dieser ganzen thematik, du entscheidest das lokal, und du hast halt nicht die Information von der anderen Not oder ähnliches. [SPEAKER_00]: Wenn du eine Not hast, ein Server, dann ist das super, weil dann hast du, dann kannst du eigentlich sagen, okay, stateless, aber dann wenn du was neu stattest, aber du kannst auch zum Beispiel irgendwelche Sachen vorberechnen und dienen Memoryler an oder ähnliches.

[SPEAKER_00]: Wird oft, wie gesagt, bei CDN oder Edge Computing genutzt oder bei Diedausmitigations Soht, wo du relativ schnell entscheiden muss oder wo du unglaublich viele Anfragen bekommst, dass du nämlich dann zu erschörenden Datenbank nicht überlassen. [SPEAKER_00]: Aber die meisten Radlimiting-Algruppen oder Radlimiting-Funktionitäten sind statefull und da habe ich die jetzt einfach mal viel verschiedene Methoden mitgebracht.

[SPEAKER_01]: Dann lieb er an, die Backmalt einen Methodenkoffer aus und präsentiere uns deine vier Methoden, die uns mitgebracht ist. [SPEAKER_01]: Das klinkst du wässer und Stabzerger verkäufe an der Tür. [SPEAKER_01]: Ich habe ihn dann mal vier Beispiele mitgebracht. [SPEAKER_00]: Fangen wir mit dem einfachsten an, der einfachste ist nicht fair, aber sehr einfach. [SPEAKER_00]: Und zwar ist das wirklich ein Fix-Winder.

[SPEAKER_00]: Du lasst halt ein festes Zeitfänzer zum Beispiel eine Minute und da in diesem Zeitfänzer sind 500 Requests erlaubt und danach wieder zieler zurückgesetzt. [SPEAKER_01]: ziemlich dumm, na einfach Ansatz würde ich mal sagen, so wenn man das ganz simple implementieren würde, wenn man mit irgendwas Staaten will oder? [SPEAKER_00]: 100 Prozent, also wie funktioniert das?

[SPEAKER_00]: Ja, in Rekels kommt rein, du erhößen Counter, das eine Minuten Fensterloff ab, du Resettest den Counter und alles über dem Limit wird abgelehnt, ne? [SPEAKER_00]: Und da schützt natürlich auch Börs, so lang bis das Limit erreicht ist, also ist es sehr, sehr einfach. [SPEAKER_00]: Warum ist jetzt unfair? [SPEAKER_00]: Ja, also unfair ist es halt deswegen, weil du Sachsheit für das Kampf hast zu öffnen. [SPEAKER_00]: Es gibt keine Drosselung, es gibt keinen Split oder ähnliches.

[SPEAKER_00]: Du hast keinen Schutz vor aggressiven Kleins, wenn es eine, wenn es denn eine zentrale API ist, dann kann ich dir einfach zumachen und du hast halt gar keinen Chance mehr auf den Service zuzugreifen.

[SPEAKER_00]: Natürlich kannst du auch Fix Windows dann noch mal separieren, Protennen, Prokunde oder Ähnliches. [SPEAKER_00]: Würde ich aber einfach nicht empfehlen, im Endeffekt, dass es ein guter Einsatz fall für, ich sag mal, einen groben Schutzmechanismus, irgendwie Internet Tools oder Low Risk APIs oder halt Systeme, wo wirklich die Einfachheit wichtiger ist als die Präzession. [SPEAKER_01]: Oder das letzte Sicherheitsnetz einfach.

[SPEAKER_00]: Ja, genau, es ist einfach nur wirklich ein grober Schutzmechanismus. [SPEAKER_00]: Okay, wenn wir jetzt einen Schritt Richtung Fernis gehen, ihr du nimmst einfach das Fix window und machst aus den Sleding window. [SPEAKER_00]: Das bedeutet, du zielst die Week West über ein gläitendes Zeitfenster und hast halt somit nicht diese festen Grenzen dabei, wie nach einer Minute im Überrad gesprochen haben.

[SPEAKER_00]: Man wie funktioniert die ganze Sache, ähnlich wie gerade Rikos kommt rein, jeder Rikos kriegten Timestamp und es zählen nur die Rikos innerhalb der letzten Sekunden und dann wird das Limit kontinuierlich gibt. [SPEAKER_00]: Du kannst ja eigentlich vorstellen, der Rikos sagt auch ein sliding window ist es wirklich. [SPEAKER_01]: Man kann meistens so ein Ringboofre implementieren, der man dann wieder verwendet, so keine Ahnung.

[SPEAKER_01]: Wenn es 60 Sekunden sehen kann man 60 Slots machen und dann [SPEAKER_01]: jeder Sekunde eingeben, wie viel request waren oder so einen so einen sliding window implementieren. [SPEAKER_01]: Hatte ich mal bei irgendeinem Bewerbungsgespräch, muss dies so ein Ringboof verimplementieren? [SPEAKER_00]: Ja, in Ringboof war es einer der sofort zu den Datenschuturen für dieses Algorithmus, eine Q oder eine Dicu oder unsere Hitze-Liste reicht auch, oder halt einfach ein Zworte zett.

[SPEAKER_00]: Kannst du auch nehmen? [SPEAKER_00]: Im Endeffekt irgendwas, wo du halt... [SPEAKER_00]: schnell diese Liste auch dauerhaft aufräumen musste. [SPEAKER_00]: Denn im Endeffekt musst du diese Liste mit einem sliding window die alten Enträger musst du halt kontinuierlich rausschmeißen. [SPEAKER_00]: Das bedeutet, du operierst halt konstant auf diese Datenschutrohrung.

[SPEAKER_00]: Und kannst du ja vorstellen, dass es halt mit Anzahl der ein genen Riequests halt schon in rechen und Speicher aufwandten. [SPEAKER_00]: Weil der Speicher wechselt mit der Riequests rater, weil du halt für jeden Riequests in Timestem mit Ablegs. [SPEAKER_00]: Also du machst einen Ringbrufer, dann hat man dieses Problem eben nicht. [SPEAKER_00]: Klar, aber trotzdem muss ja immer noch einen Klin amachen.

[SPEAKER_01]: Ja, beim Rinkbuffer überschreibst du einfach das Ganze darum, ist es relativ effizient. [SPEAKER_00]: Genau. [SPEAKER_00]: Und dann muss sie die ganze Sachen natürlich auch hohe Zutatz gelieren können. [SPEAKER_00]: Das bedeutet, wenn du das nur in Memory hast, dann wird es auch wieder schwierig. [SPEAKER_00]: Aber im Endeffekt ist das halt ein guter Einsatz, wenn dir fernes wichtig ist. [SPEAKER_00]: Und wenn du systemen, ich sag mal mit moderater Lasthaus.

[SPEAKER_00]: Ich würde es halt nicht bei sehr hohen Request-Raten implementieren, weil dann brauchst du hohe Ritzenthales Relierung, die dann mal ringenbar verscher wird. [SPEAKER_00]: Der Schreibvorgang mag zwar toll sein, aber wie es solltest du den über dein Memories hinweg. [SPEAKER_00]: Die beiden Algorithmen Fixed Winder und Sliding Winder, der Herr Aprox, die der Lodbellen zur Hat, die zum Beispiel implementieren. [SPEAKER_00]: Also da kannst du beide wählen.

[SPEAKER_00]: Jetzt kommen wir zu einem Weg, den ich sehr, sehr schön finde, und der auch sehr, sehr oft bei AWS und auch in den AWS Kleins implementiert ist, oder in den AWS Kleins SDKs. [SPEAKER_00]: Und zwar ist es das Token-Baket, das haben wir glaube ich schon mal in der Episode zu Timeouts und Back-Offs und Exponentsche Back-Offs besprochen. [SPEAKER_00]: Im Endeffekt hast du ein Eimer und erfüllt sich kontinuierlich mit Tokens und jeder Request Verbrauch ein Token.

[SPEAKER_00]: Und es kommen in diesen Eimer immer neue Tokens in zu über eine Konzanterate. [SPEAKER_00]: Also stell dir vor, du hast ein Eimer, da kommen 5 Tokens pro Sekunde rein und in den Eimer passen 10 Tokens. [SPEAKER_00]: Jeder Request Verbrauch ein Token. [SPEAKER_00]: Jetzt kommst du an, machst deine Mobile App auf und schicks 8 Request auf einmal. [SPEAKER_00]: Du machst dein Börst.

[SPEAKER_00]: So mit Verbrauch deine App gerade 8 Togens, 2 Togens sind noch in dem Eimer und alle 8 Request sind erlaubt. [SPEAKER_00]: In den nächsten Sekunde fühlt sich der Bucket wieder, also fühlt sich der Eimer wieder mit 5 weiteren Togens. [SPEAKER_00]: Als weil 5 Togens diese Kunde reinkommen, bis er wieder 10 Togens im Eimer sind und dann geht es immer so weiter. [SPEAKER_00]: Jetzt hast du einen kleinen, der schickt 12 Request sofort, die ersten 10 Request sind erlaubt.

[SPEAKER_00]: die zwei Request werden abgelehnt oder verzögert, da kommt es auf die anderen Implementierung an. [SPEAKER_00]: Nächste Sekunde kommen wieder fünf Tokens rein und so mit es wieder frei für neue Request. [SPEAKER_00]: Schützelt wirklich dann für die Becken überlastet.

[SPEAKER_00]: Es ist ein bisschen komplizierter zu implementieren, ist aber sehr flexibel und finde ich es eine guter belangs zwischen, ich sag mal, Schutz und Nutzerfreundlichkeit, weil danach relativ schnell wieder die Bahn frei ist. [SPEAKER_01]: So, jetzt haben wir gerade überlegt, was ist eigentlich der Unterschied zum Sliding Window?

[SPEAKER_01]: Weil ein Sliding Window bekommt ja auch mit einer konstanten Rate im Prinzip wieder Slotz zu geordnet, wenn du jetzt sagst, du hast jede Sekunde einen Slot, wo du die Request abspeich hast. [SPEAKER_01]: Dann ist es ja sehr nahe am [SPEAKER_01]: Bucket und Börst sehen auch, weil du hier in dem Window ein Börst machen kannst. [SPEAKER_00]: Du kannst ja unter anderem die Anzahl der Tokens, die pro Zeitfänzer in das Bucket überfließen kannst du den Name schalten.

[SPEAKER_00]: Zum Beispiel noch hat deine Infrastruktur. [SPEAKER_00]: Kannst du mal am Sliding-Winn noch nicht. [SPEAKER_00]: Am Sliding-Winn noch kannst du nur das ganze Windhof verschnellern oder nicht. [SPEAKER_01]: Stimmt, und deshalb gar nicht gedacht, wo ich den Unterschied zusätzlich noch sehe ist, dass der Buckhead mit einer konstanten Rate arbeitet. [SPEAKER_01]: Das heißt, es fließen immer konstant viele Dawkins nach.

[SPEAKER_01]: Bei einem sliding window hast du aber diesen Effekt, dass wenn du am Anfang extrem hohe Börstrate hat ist. [SPEAKER_01]: Das heißt, in deiner ersten Sekunde von deinem [SPEAKER_01]: Und des Windows springt dann um genau diese Sekunde weiter, dann fallen die plötzlich diese 100 Request dieser Riesenburst fällt ihr hinten einfach raus.

[SPEAKER_01]: Inhalb einer Sekunde hast du plötzlich von 100 Request in deinem Windows Nummer zwei Request von einer auf die andere Sekunde, weil eben des Windows [SPEAKER_01]: so springt. [SPEAKER_01]: Beim Bucket hast du konstant, dass genau in dem Fluss so viel der Tokungsvideo reinfößt, konstant immer dazu gegeben werden, ohne dass du so extremisch springe trin hast, wie mit dem Windows. [SPEAKER_01]: Es war zu meiner Erklärung, wo es auch noch ein Unterschied gibt.

[SPEAKER_01]: Also genau wie du sagst, es ist eigentlich dynamischer und konstanter und ein bisschen flüssiger im wahrsten Sinne des Wortes. [SPEAKER_00]: Das ist auch ein sehr, sehr guten Punkt gebracht. [SPEAKER_00]: Ich würde sagen, es ist halt wie die Anfragen gezählt und gegletze und zugelassen werden. [SPEAKER_00]: Es ist halt so der kleine Unterschied. [SPEAKER_00]: Aber im Endeffekt kommt es unten dran, halt schon das Leiche überraus für die sagen.

[SPEAKER_00]: Und wenn wir schon mal einmalen sind, dann kommen wir zu der letzten Methode, dem Ligi-Bucket, dem Tropfen in Einmal, wenn das so möchte ist. [SPEAKER_00]: Und das ist eigentlich... Das heißt, erstens Kübel. [SPEAKER_01]: Und gibt es dann nicht, das ist doch der Liedbahrechen-Datschand. [SPEAKER_01]: Der Einmal hat dann Loch lieber Heinrich Gustav. [SPEAKER_01]: Nein, lieber Reinhardt war, das war Reinhardt Mai.

[SPEAKER_00]: Ein Loch ist im Eimer, sein deutsches Volks- und Kinderlied. [SPEAKER_00]: Es kenne es zu gar nicht an die. [SPEAKER_01]: Jetzt lasst du dir von dem Österreicher, was er klären. [SPEAKER_00]: Im Ende der Weg hat das, jetzt relativ wenig mit einem Eimer zu tun, denn die ganze Sache ist ein Cuba-Sietersmodell, wo dann halt die Wicus mit nur Konzernrader abgearbeitet werden. [SPEAKER_00]: Also, wie funktioniert es ein Wicus-Kon-Drein?

[SPEAKER_00]: Landen in der Q und dann tropfen die hinten halt in der fixen Ratteraus. [SPEAKER_00]: Und wenn die Kieuheit einfach voll läuft, dann werden die Mikristen einfach vorworfen. [SPEAKER_00]: Also ich meine, in der Vorteil, du hast eine relativ gute stabiles Lassprofil, weil du halt die Ausdropfrate, also die Verarbeitung, dann eine Mikristen als selbstbestimmen kannst. [SPEAKER_00]: Und du hast halt einen unglaublich gut vorher siebares Verhalten.

[SPEAKER_00]: Und nachteile ist halt dann gegeben, falls höhere Latents kann halt keine Börs oder ähnliches unterstützen. [SPEAKER_00]: Und je nach Service kann es natürlich, dass nur zu erlebens verschlächern, wenn die Latents hoch ist. [SPEAKER_01]: Warum kannst du keine BEST? [SPEAKER_01]: BEST hast du ja genauso, oder? [SPEAKER_00]: Ja, die BEST werden halt einfach in die Q geschrieben, aber die BEST werden nicht schneller abgearbeitet.

[SPEAKER_00]: Und BEST ist ja, dass ganz viele Wücke so einmal kommen und dann die Antwort auch zügig kommt. [SPEAKER_00]: Hier machen die BEST halt einfach nur die Q relativ voll, aber die Antwort geht dann nicht schneller raus, weil du ja die Wücke West in einer fixen Warte abarbeitest. [SPEAKER_01]: Und warum sagt man ja einfach Q dazu? [SPEAKER_01]: Zum Liki Bucket? [SPEAKER_00]: Das musst du die Menschen fragen, die das erfunden haben.

[SPEAKER_00]: Keine Ahnung, vielleicht fragst du mal bei Engine X-Nachs. [SPEAKER_00]: Weil die fahren das Modell zum Beispiel Radial with the Manger X. Aber warum verarbeitet ich nicht mehrere Requestes am Barallelle aus dem Buckhead? [SPEAKER_00]: Kannst du doch. [SPEAKER_00]: Ich mein, du hast ja, also wie du die verarbeitest, ist ja egal. [SPEAKER_00]: Aber du du definierst für die Konstantinrate.

[SPEAKER_00]: Wenn du zum Beispiel einen Worker Pool hast, dann kannst du ja trotzdem X mal aus der Q-Lesen. [SPEAKER_00]: Ah, okay, also ich entscheide, wie groß das Loch ist im Paket. [SPEAKER_00]: So ungefähr. [SPEAKER_00]: Du darfst, der Unterschied ist, wenn du in einer Bors oder in Kübel, ja, dann kannst du es halt nicht wieder zu machen, hier halt schon. [SPEAKER_00]: Okay, I see. [SPEAKER_00]: Und das kann ein schönes Ex-Default-Mesik.

[SPEAKER_00]: Genau. [SPEAKER_00]: Zum Beispiel der Token-Baket, die man gerade erklärt haben, das ist zum Beispiel im End-Wäude drin oder Kong, das ist diese API Gateway, die machen zum Beispiel das mit dem Token-Baket oder halt bei Ederbüge erst sehr viel. [SPEAKER_00]: Ich spreche mir die ganze Zeit über engineering-team, aber meine Sache nach ist rate limiting, jetzt nicht nur in engineering-entscheidung, sondern auch eine Produktmanagementfrage. [SPEAKER_00]: Kannst du dir vorstellen warum?

[SPEAKER_01]: Ja, wenn ich jetzt entscheide bei OpenBotcast, dass ich dir an dir als mein User nichts mehr ausliefer hätte, ist es ja wohl eine Produktentscheidung und wann nicht dir nichts mehr ausliefer, weil du mir nichts zahlst und meine anderen Kunden mir aber schon was zahlen und dir dann die Priorität natürlich. [SPEAKER_00]: Ja, du sprichst an wichtiges Thema an einem Endeffekt, kannst du über Rätlimetinktes definieren, wer dein Produkt wie Intensiv nutzen darf.

[SPEAKER_00]: Das ist halt so eine Art Werte versprechen, dann ist Software-Service. [SPEAKER_00]: Denn Rätlimetinkentscheidet wirklich halt über die Zuginlichkeit, über die Preosierung und auch Achtung, über die Monitorisierung und das Kunden erleben ist. [SPEAKER_00]: Denn im Endeffekt kannst du auch Rätlimetink bewusst, einsetzen, um zum Beispiel irgendwie einen Absel zu machen. [SPEAKER_00]: Du kannst Rätlimetinklerk als Software-Woll sehen. [SPEAKER_00]: Niemand mal als Beispiel Github.

[SPEAKER_00]: Github hat ättlicher Radel mit. [SPEAKER_00]: An Nüme User können mit der Github API sprechen, die dürfen aber nur 60 Anfragen pro Stunde machen. [SPEAKER_00]: Also eine Anfrage pro Minute. [SPEAKER_00]: Wenn du aber eingelockt bist, darfst du 5.000 Anfragen pro Stunde machen.

[SPEAKER_00]: Und dann bricht sich die ganze thematik auch dann sogar nach Service auf. [SPEAKER_00]: Also Github hat eine Funktionität, die nennt sich LFS Large File Storage. [SPEAKER_00]: Da kannst du zum Beispiel der Teilen [SPEAKER_00]: Da können unautentifizierte User 300 Requests die Minute machen, Autentifizierte User 3000 Requests. [SPEAKER_00]: Oder GitHub Apps haben auch unterschiedliche Rathle-Mist.

[SPEAKER_00]: Ob du jetzt ein eingelockter User-Bist oder ob diese GitHub App von einem Enterprise Cloud-Account gesteuert wird oder oder oder. [SPEAKER_00]: Im Endeffekt kann zu damit halt wirklich deinen Kundenzugang steuern. [SPEAKER_00]: Du kannst halt so wie du jetzt das gerade auch beschrieben hast, freite ihr User anders behandeln als Enterprise. [SPEAKER_00]: Und wie kommen die Ziere ich das Ganze an den Jusser?

[SPEAKER_01]: Also, abgesehen von den Terms in Konditions, dass das irgendwo steht. [SPEAKER_00]: Ja, im Endeffekt geht's da jetzt darum, auf welche Parameter du dann Redlementing setzt. [SPEAKER_00]: Entweder ist es so, z.B. [SPEAKER_00]: die Rate, also den Durchsatz, also die erlaubten Greek West Prozeit einheit, 100 Greek West diese Kunde. [SPEAKER_00]: Dann haben wir gerade über die Börs gesprochen, wie viel Request lässt du kurzzeitig über die Rate hinweg durch.

[SPEAKER_00]: Du kannst ja auch sagen, okay, obwohl du 100 Request die Minute machen darfst, darfst du in zwei Minuten von zehn Minuten. [SPEAKER_00]: über 10% über das Limit hinausgehen. [SPEAKER_00]: Das geht ja auch. [SPEAKER_00]: Du kannst sagen, worauf wird Limitiert, auf die IP-Adresse, auf die User ID, auf den API-Ki, auf einen Tenant, du kannst sagen, wie wird dein Rade Limit hingesteuert?

[SPEAKER_00]: Also dein Enforcement Mode, ein Hard Limit, also lehnt zu jeden Request-Up, oder sagst du, hast ein Soft Limit, du verzögerst dann, die Antwort sei in die Privacyse oder Drosselsie. [SPEAKER_00]: Du kannst nur unterschiedliche Gewichtung auf die Art des Request legen. [SPEAKER_00]: Du kannst sagen, okay. [SPEAKER_00]: Nen Laser Request, also in GetRequest, ist günstiger als ein Post-Request, weil ein Post-Request dann eben zum Beispiel schreibt.

[SPEAKER_00]: Du kannst uns zum Beispiel sagen, wie mit der Bucket-Schrategie, die wir gerade gefahren haben. [SPEAKER_00]: Laser Request vor Wochen ein Bucket, schreibt Request vor Wochen fünf Buckets. [SPEAKER_00]: Du kannst sagen, wenn man System unterlast ist priorisierig, Enterprise Kunden über Freakunden und so weit hat. [SPEAKER_00]: Und das ist die Art von Kommunikation, die du machen musst. [SPEAKER_00]: Du musst deine Parameter festlegen und dann wo nach du runterbriss.

[SPEAKER_00]: Und da kommt es wirklich auf eine gute Kommunikation zwischen Engineering und Produktmännenschment an. [SPEAKER_00]: Denn Engineering muss die sagen, was kann meine Infrastruktur, wo er aufkannig limitieren, wo er aufmachte Sinn zu limitieren, welche Operationen sind teuer, welche sind günstig und da komproduktmännenschment, wie die das Produkt positionieren wollen und kommunizieren wollen.

[SPEAKER_01]: Okay, das ist ja jetzt immer noch die Kommunikation eher auf der Produktzeite, wie kann ihr das ganze Technisch kommunizieren über die API abgesehen jetzt von meinem 4.9.20er, der immer ins Gesicht springt. [SPEAKER_01]: Also wenn wir jetzt beim HTT-P Protokoll bleiben, dann sind klassische Responsehänder so die Antwort. [SPEAKER_00]: Die Antwort im Westen Szene des Wortes. [UNKNOWN]: Ja, die Antwort. [UNKNOWN]: Ja, das ist mein Response.

[SPEAKER_00]: Ich nehme mal wieder GitHub als Beispiel, weil ich finde die machen auf der einen Seite relativ viel richtig und zwar, wenn du mit der GitHub API spriches Christu 5Header zurück. [SPEAKER_00]: Und die sind sehr explizit, die geben dir einen Limit Header zurück, das sagt dir einfach, wie viel Request zu pro Stunde machen kannst.

[SPEAKER_00]: Die geben dir einen Remaining Headard zurück, wie viel Request du in dem aktuellen Zeit wenn du noch offen hast, die geben dir dann auch die Deferenz davon zurück, also die Use, wie viel Request du im aktuellen Zeit wenn du vorbraucht hast, dann geben dir die sogar mit die Art von Ressource, worauf das Rathlete mit dem ist, geht LFS, hat man gerade zum Beispiel genannt und weil ich auch sehr nett finde, die geben dir einen TimeStamp mit

[SPEAKER_00]: Und da kann es natürlich kleinmäßig super viel machen. [SPEAKER_00]: Du kannst dynamisch trimer setzen, du kannst sogar die Anzahl der Request in dem aktuellen Zeit, wenn du ausrechnen und dann drohseln. [SPEAKER_00]: Du kannst richtig nette Klein schreiben. [SPEAKER_00]: Anders Beispiele, also GitHub ist ja sehr explizit, die geben dir fünf Häder und die haben ja doppeltere Informationen, wie zum Beispiel Limit Remaining und Use. [SPEAKER_00]: Das kannst du dir auch ausrechnen.

[SPEAKER_00]: Cloudflay ist ein bisschen sparsamer, Cloudflay gibt dir nur zwei Häder zurück. [SPEAKER_00]: Das hält aber eigentlich die gleichen Informationen nur halt, die haben musst du den Häder-Weljuhald paßen. [SPEAKER_00]: Kannst du mal ein bisschen positiv für deinen Arbeit gebersprechen? [SPEAKER_01]: Ja, ist doch positiv. [SPEAKER_01]: Wir kümmere uns halt darum, dass wir nicht so viel Netzeltransfer haben.

[SPEAKER_01]: Aber Lesbara findet ja schon GitHub als Cloudflab, muss ich mal sagen. [SPEAKER_01]: Also da irgendwelche mehrere Werte in einen Headermit reinpacken und so. [SPEAKER_00]: Ja, der... [SPEAKER_00]: Der Unterschied ist, du bist ein Mensch und für Maschinen ist das relativ egal. [SPEAKER_00]: Denn Achtung, Klaufler ist aber so nett und zwar implementieren die nämlich den Retry-After-Header, der bereits seit Hattet P1.1 ist, nämlich standardisiert ist.

[SPEAKER_00]: Und ich de-Stack davon aus, dass GitHub einfach die API gebaut hat, bevor dieser Headerschnotisiert war und sind nie angepasst haben. [SPEAKER_01]: An die musste sehr zahlsarbeitnehmer von Cloudfluss sagen, dass sie netzen, ihre Zanglieferwenden so einen ur alt-Produkoll hat der DB-1.1, das ist ja eine Neunzigerverstum. [SPEAKER_00]: Ja, nur weil es in 1.1 standardisiert ist, heißt das nicht, dass es nicht in die nächsten Hattel-Pivision mit übernommen wurde.

[SPEAKER_00]: Aber im Endeffekt jetzt gerade läuft auch eine neue FC für die anderen Rate-Limiting Weller, wo das letzte Mal im September 2025 abdätet, also ist wirklich ungüring, verlinkt euch auch in den Schunnen usw.

[SPEAKER_00]: ein bisschen mal in den schönen FC reinkucken möchte und damit mal die ganze Rate-Limiting header, masset dann auch mal standardisiert und weil im Endeffekt musst du jetzt für jeden Service eigentlich andere Häder auslesen und das sind finich ein bisschen [SPEAKER_00]: Aber wir sprechen jetzt immer darüber, dass Raid Limiting ein System für überlastsschützen soll. [SPEAKER_00]: Wir hatten ja gerade über Statefull und Stateless Raid Limiting Algorithmen gesprochen.

[SPEAKER_00]: Und in all diesen Algorithmen hast du ja in irgendwo, ich sag mal, eine zentrale Datentwelle, wo du einen Counter-Raus nimmt oder einen Buckhead oder einen Token oder haben wir jetzt auch eine Konfigationswert, wie viel Tokens in ein Buckhead kommen und so weiter. [SPEAKER_00]: Du brauchst halt jeden Fall irgendeine Kommunikationsstille mit der dein Algorithmus arbeitet. [SPEAKER_00]: Was passiert denn jetzt eigentlich, wenn dein Rate-Limiting Algorithmus viel schlägt?

[SPEAKER_00]: Also das bedeutet, wenn dein Rate-Limiting Algorithmus ein Teil modkrägt. [SPEAKER_01]: Das ist so ähnlich wie die Frage, wer Monitor das Monitoring System, oder? [SPEAKER_01]: Wer ist das Sicherheitsnetz, wer das Sicherheitsnetz? [SPEAKER_00]: Ganz genau, was passiert dann? [SPEAKER_00]: Ich meine, es gibt Netzweggpartitions, dein Redis kann abstürzen, du kannst ein Back in der Limitlogik haben. [SPEAKER_00]: Ja, Ready ist verwendet doch niemand.

[SPEAKER_00]: Ja, warum ihr so auch Memke schon mal zu älteren. [SPEAKER_00]: Was ist der Egal? [SPEAKER_00]: Aber was machst du dann? [SPEAKER_01]: Wie würdest du dich verhalten? [SPEAKER_01]: Als Redel mit der Europa? [SPEAKER_01]: Also meine Meinung nach gibt es drei Möglichkeiten. [SPEAKER_01]: Ich lasse alle Request durch. [SPEAKER_01]: Mir doch egal. [SPEAKER_01]: Ansatz. [SPEAKER_01]: Dann wird halt wahrscheinlich das System sterben, Freude später. [SPEAKER_01]: Zwei der Extrem Ansatz.

[SPEAKER_01]: Ich lasse gar keine Request mehr durch. [SPEAKER_01]: Mein System wird nicht sterben, aber die ganzen Kunden werden angebisern. [SPEAKER_01]: Oder die dritte Variante, ich habe irgendwie in BackCub System. [SPEAKER_01]: Im Sinne von z.B. [SPEAKER_01]: den ganz naheifen Algorithmus, der dann nur lokal entscheidet, einen lokalen Counter hat und eben keinen geschärten Städt. [SPEAKER_01]: Und auf eine Stufe zurückschaltet.

[SPEAKER_01]: Und je nachdem, wie komplex mein System ist, weil ich wahrscheinlich in BackCub haben oder nicht. [SPEAKER_01]: Wer zu meine Konzalting schnell antwort. [SPEAKER_00]: würde ich zu zwei dritteln mitgehen, obwohl die Sicherheitsnetz finde ich auch nicht schlecht, aber auch der kann ja dann back in der Logik haben, also da bisher dann wieder auf dem irgendwann wird dann habe ich dann die Entscheidung entweder plockig alle sogar nichts mehr.

[SPEAKER_00]: Also mehr Infekt reden wir hier gerade über ein Konzept, das hat sich Fail Open Versus Fail Closed und da ist die Kiefrage, was machen wir, wenn wir nicht wissen, ob ein Rikwester glaubt ist oder nicht. [SPEAKER_00]: Und weil ich ja gar gesagt, ein Rate mit da kann ausfallen oder unentscheidbar werden den was mal.

[SPEAKER_00]: Fail Open ist genau das, was du auch gesagt hast, wenn der Redlementer nicht entscheiden kann, lasse mir den Request einfach durch und Fail Close ist, wenn der Redlementer nicht entscheiden kann, blockieren wir einfach den Request. [SPEAKER_00]: Und ich will sagen, Beides ist auch eine Valide Lösung, es kommt halt wirklich nur drauf an, was wir denn gerade geschützt.

[SPEAKER_00]: Wenn du jetzt die Fail Open Logik bei einem Admin API Panel machen würdest, weiß ich jetzt nicht, ob das hier richtige Lösung ist,

[SPEAKER_00]: Da würde ich dann zum Beispiel beim Admin API-Pennel oder bei Security-Relevanten nennt Produkten, da würde ich dann eher die FAI-Clos-Variante nehmen, einfach mal mehr Request-Blocken, aber wenn du jetzt zum Beispiel klassische User-Facing API-Has oder kritische Geschäftsprozesse oder wenn verfügbarkeit über Sicherheit steht, dann kannst du auch FAI-Lopen machen.

[SPEAKER_00]: Deine dritte Variante fand ich auch ganz interessant, ich würde aber eine andere Vorschlagen und zwar würde ich ein Hybrid Modus zwischen Fail Open und Fail Close Vorschlagen Fail Open bei Lesary Quest oder bei Autantivizierten User zum Beispiel, wenn der User Autantiviziert ist, lasst es einfach durch den Request

[SPEAKER_00]: Fail closed bei anonymem Traffic, bei hat den Appearation oder bei Schreiboperation, weil dabei sehr nie, weil da kannst du die Datenbank ja wirklich mit runterziehen oder du machst die ganz Sache zeitbasiert, du machst für eine gewisse Zeit, Fail Open und dann kommt halt irgendwann vielleicht das Backpatcher Signal von dem mal gerade auch gesprochen haben und dann switch

[SPEAKER_00]: Das System, offen zu halten, fand ich funktioniert, bevor ich das ganze System Rotarzi mache, ich dann lieber Feldklost, bis mein Backperger sich wieder erholt hat und dann schaltet super um auf Fälle. [SPEAKER_01]: Und da gibt es auch sicher noch fünf andere Varianten, die man fahren kann in Zuhi-Preet oder Backkap-Modi. [SPEAKER_01]: Ja, Dörner kreativität sind da keine Grenzen gesetzt, ne?

[SPEAKER_01]: Die Frage ist es nur globaler Entscheidung, oder ist es vielleicht nur für einen Zubklaster? [SPEAKER_01]: Und wenn ihr dann weiß, die der Rest vom Klasse wird schon irgendwie sinnvoll reagieren, könnt ihr vielleicht auch mich einfach abschauten, weil ihr weiß, dass der Rest vom Klasse in irgendeiner Form noch weiter reagieren wird oder so. [SPEAKER_01]: Wer auch eine Möglichkeit, als ich glaube, da gibt es viele Möglichkeiten.

[SPEAKER_00]: Aber du merkst schon, ich meine, wir sprechen hier jetzt schon nur über das Konzept und wenn wir jetzt mal in einer Firma werden mit 100 Leuten, wo also 100 Software-Engineers sind und ätliche mehr Applikationen. [SPEAKER_00]: Also meinst du eigentlich, wer kann eigentlich diese ganze Komplexität wann, wie, wo, Great Limitil, wird und wo, was auf Zuschel steht, wer, wer hält das denn überhaupt noch ein Kopf?

[SPEAKER_01]: Wobei ich das sagen muss, dass es eigentlich hier über die ganzen hat der D.B. [SPEAKER_01]: Heder und Status kurz, wenn man da sinnvolles Weg findet, kann man ja eine relativ unabhängige von anderen agieren. [SPEAKER_01]: Und klar, muss das jedes T-Machen und man muss sauber agieren und netten Kleinschreiben und jedes Service-System ist wahrscheinlich auch irgendwo ein Kleinsystem für ein anderes Service-System und so weiter.

[SPEAKER_01]: Aber ich finde, die hatte die Beschnittstelle ist eine relativ sauber gelöst und da gibt es [SPEAKER_01]: Man muss ja nur im Schirm haben und entscheiden, was man damit macht. [SPEAKER_01]: Aber dann kann man eigentlich sehr lokal in seinem Skope agieren. [SPEAKER_01]: Und braucht gar nicht jetzt irgendwie nen Chief Rate Limiting Officer oder keine Ernährung, der dann die Gesamtarchitektur in der Hälte oder in den Überblick behält.

[SPEAKER_00]: Du hast mir gerade die beste Überleitung gegeben, die es gibt. [SPEAKER_00]: Jetzt bin ich gespannt. [SPEAKER_00]: Also erstmal, sagst du gerade, wenn sich alle an die vierem Standard halten würden, dann hätten wir alle kein Problem. [SPEAKER_00]: Ich bin ja ein Mensch, dass er positiv denkt und das Gute sieht. [SPEAKER_00]: Jeder, jeder, der der größeren Organisation arbeitet, denkt sich, ich ach du meine in die Güte, dass wir eine volle Welt.

[SPEAKER_00]: Aber du hast ja gerade gesagt, wenn man den auf die HTT-P-Status kurz achten würde. [SPEAKER_00]: Und dann kommt der Kollege, um die ecke, der gerade eine Graf-Guell API implementiert hat. [SPEAKER_00]: Fischfrage. [SPEAKER_00]: Wie retoniert Graf-Guell ein HTT-P-Ero, mit welchem Statuscode? [SPEAKER_00]: Bin kein Fan von Graf-Guell. [SPEAKER_00]: Kannst du die Frage, den wir anwohnt?

[SPEAKER_00]: Mit 200. [SPEAKER_01]: Das heißt, ich muss mir dann selber was Sie implementieren, in meinem Protokoll, höchst du wahrscheinlich, oder? [SPEAKER_00]: Ja, eine Grafkuell-Schnittstelle selbst gibt dir den Ero im Payload, ja, im Payload mit, ja. [SPEAKER_00]: Die Frage ist aber eigentlich, wie ermittels du denn, ob du einen Rade Limit triggernt musst oder nicht. [SPEAKER_00]: Wir reden in der ganze Zeit über hat der TPP-Request.

[SPEAKER_00]: Und wenn wir jetzt über REST API sprechen, dann ist es ja recht einfach, weil ein Request ist dann ein Counter-In-Rade Limit und so weiter und so fort. [SPEAKER_00]: Aber Grafkuell, das hat ja schon eine Name Grafkary-Lang-Witsch. [SPEAKER_00]: Ja, also stellt ihr vor SQL-Ober-HTTP.

[SPEAKER_00]: Es ist nicht ganz SQL, aber das bedeutet, du kannst, das tolle ist ja, dass du damit Request Bündeln kannst und flexiblere Rest API-Spawn kannst, wo du bei Rest API 20 Request machen musst kannst du mit GraphQL eine Query-Bauen, die dir nur die da zurückgebt, die du brauchst und so weiter und so.

[SPEAKER_00]: Aber du merkst jetzt jetzt kommt schon die ganze Komplexität an den Tisch, wie ermittels zu den Rate-Limmits bei GraphQL. [SPEAKER_01]: Ja, aber das selber Problem hat es bei Rest APIs auch, weil manchen Rest API-Kores in super Aufwendig, manche brauchen viele Rissosen, manche Triggeren hinten 20 Requests, manche anderen nur einen Requests. [SPEAKER_01]: Also die Grundproblematik hast du ihr weiterhinde, dass du wissen musst, was ist das in vielen Request?

[SPEAKER_01]: Wie komplex ist der Request? [SPEAKER_01]: Wie behandelt du dann in deinem Backhead durch die Zwersion erwähnt? [SPEAKER_01]: Manche queries haben vielleicht fünf. [SPEAKER_01]: Tokens, manche andere queries haben nur einen Token, ist es schreibt zugriff, flasse zugriff und zu weiter. [SPEAKER_01]: Also selber hast du bei GraphQL. [SPEAKER_00]: Nehmen wir noch mal ein Infrastruktur basierten Rätelmitter dazu.

[SPEAKER_00]: Ja, nehmen wir mal du hast eine REST API und du hast Load-Bellenzeller nehmen, so ein Envoy oder H-A-Proxier. [SPEAKER_00]: Ist ja egal, wo eine Engine X von mir aus. [SPEAKER_00]: Und da brauchst du jetzt das Rätelmitter an. [SPEAKER_00]: Bei einer REST API kannst du pro Endpoint dann eine Rätelmitter gesetzen.

[SPEAKER_01]: Auch bei einem Core von einem Endpoint kann die passieren, dass ein Core sehr teuer ist und ein anderer Core sehr günstig, obwohl es dieselbe API ist, das selber API Endpoint. [SPEAKER_00]: Du meinst, wenn man das über Querypar mit der Schleuren kann? [SPEAKER_01]: Ja, zum Beispiel Querypar mit oder wir haben zum Beispiel bei unseren REST APIs. [SPEAKER_01]: Manche Podcasts, die extrem viele Episodeen haben und dadurch reinen die Queryts viel viel länger.

[SPEAKER_01]: Da ist der deutsche Begriff mal einfacher. [SPEAKER_01]: Laufzeiten, obwohl es die selber API ist. [SPEAKER_00]: Okay, bei dir hört sich also die Laufzeit pro Datenvolumen. [SPEAKER_00]: Kann passieren, ja? [SPEAKER_00]: Genau, das sage ich, ist okay. [SPEAKER_00]: Dann hast du meines Erachtens nach ein Problem mit der Wartenhaltung.

[SPEAKER_00]: Weil das ist generell ein... [SPEAKER_00]: Riesenproblem, bei Grafkuelles, aber das Riesenproblem ist, du kannst gar nicht abschätzen, was der macht ohne die Querie zu insbezieren, die ihr im Payload mitgeliefert wird. [SPEAKER_00]: Weil du hast ja alles nur über einen Endpunkt und der liefert ja immer nur 200 zurück.

[SPEAKER_00]: So und wenn du jetzt ein Infrastruktur, was ihr in Rettelmütter hast, dann funktioniert das nicht, weil ihr sieht ja nur, aha, da kommt ein HTP-Koll rein, der geht über den Endpunkt und der liefert 200 zurück.

[SPEAKER_00]: Aber du kennst die Komplexität und ich habe die Komplexität, kann bei GraphQL sehr, sehr hoch sein, weil du kannst tiefer Verschaftelungen haben, du kannst große Listen, du kannst Fähne oder über verschiedene Resolver haben, also wie funktioniert, GraphQL, du kannst in der Query entgegen nehmen und hast du ein GraphQL-Paser und für jeden Subtree, dann ist Queryis, Baufs zu hintern, so eine Art Resolverklasse und diese Resolverklasse kann man verschiedene Datenquellen anzupfen.

[SPEAKER_00]: Das bedeutet, [SPEAKER_00]: Deine Eine Grafky LAPI kann natürlich ein ganz klassischer Microsoft-Service-Fanaut, so so diese Traffic-Empelifikation, die wir gerade erwähnt haben, auch machen. [SPEAKER_00]: Aber wie löst du das Problem jetzt? [SPEAKER_00]: Du musst so eine Art Kostenberechnung für das Query bauen. [SPEAKER_00]: Du musst also dein Query in den Abstagsyntagsviel übersetzen und diese ganze Sache dann durchtreversieren.

[SPEAKER_00]: Und dann für jedes Feld irgendein Basis kosten Wert ansetzen. [SPEAKER_00]: Wie zum Beispiel keine Ahnung pro Feld oder pro Resolver, [SPEAKER_00]: Das Horses ist jetzt meine Rate-Limiting Einheit und wenn du sagst, du hast eine Rekozion, dann multiplizierst du das und so weiter und so fort.

[SPEAKER_00]: Im Endeffekt machst du eigentlich immer eine Worstcase-Berechnung, du errechnest dann immer den teuersten möglichen Fahrt und hoffst dann, dass du konservativ anstatt optimistisch gerechnet hast und deine Grafgöl API, das dann noch aussieht.

[SPEAKER_01]: Aber du könntest es eigentlich auch in deinem Responds her damit senden, oder du könntest die Kosten in deinem Responds her damit senden und Envoy oder der Reverse Proxy, der da auch der Zwischenhängt, kette dann anhand von dem Responds kostenwert dem Buckhead zum Beispiel auffüllen oder verringern, was es auch dann dem entsprechend ist. [SPEAKER_00]: Ja, du musst ja deine Rate-Limiting-Information in der Responds mit senden, weil sonst kann der Kleine ja gar nicht reagieren.

[SPEAKER_01]: Ja, klar, aber es muss jetzt nicht da der Envoy, der Reverse Proxie berechnen, diesen Kostenfaktor, sondern es kann die Applikation selbst machen und dann im Respons mit Schicken und Envoy macht dann aber das Management davon. [SPEAKER_01]: Keine Ahnung, ob das Envoy kann, aber das wäre eigentlich der gewaltender Erlung sozusagen. [SPEAKER_01]: Envoy entforscht das Ganze, aber die Berechnung läuft dann hinten im Bekannte im Code in deine Applikation abnehmen.

[SPEAKER_00]: Nur die GraphQL API selbst, der weiß ja wie teuer jeder Resolver ist und so weiter. [SPEAKER_00]: Du kannst ja auch einen In-Memory Resolver haben, der ist super schnell und wenn du halt einen Tap Storage Hass oder AWS Glacier oder sowohl halt einfach mal, weil sie nicht 50 Sekunden auf deine Response Dauer, wartest, das ist halt teurer. [SPEAKER_01]: Aber genau das, glaube ich, dass man das bei Rest-Cable auch hat, weil auch dieses Beispiel du greiftest auf eine Datei zu.

[SPEAKER_01]: Das ist Simpler API Core, die Datei kann aber auf einem tiered storage liegen ganz hinten und wo kalt und muss erst mal nach vorne gebracht werden, dauert super lang.

[SPEAKER_01]: Der andere Datei ist vielleicht hot in memory in dieser Forder, also du hast, glaube ich, bei Rest auch diese selben Probleme, wenn auch vielleicht nicht so flexibel wie mit [SPEAKER_00]: Der massive Unterschied ist nur, dass du es bei Rest in der Regel über ein Endpoint hast und bei Rest haben kannst und bei Grafkell ist es umgänglich, weil das ist das Prinzip dieser LPI-Chinchel.

[SPEAKER_01]: Also du hast ein gutes Datenbank-Team, was die Datmags so optimiert hat, das ist das Problem nicht geklärt. [SPEAKER_00]: Nee, das ist wenn du wachbar Grafköl mit Rekozion ankommst, ist Ende. [SPEAKER_00]: Also, da ist, deswegen, also, wie, den wir uns sagen, ich nehme aber noch mal Github als Beispiele, denn Github hat neben seiner REST API auch einen Grafköl API und die haben ihre komplette Grafköl-IST-Berechnung für Eureteln mit denen ich offen gelegt, dort kannst du ganz genau.

[SPEAKER_00]: In der Dokumentation sehen, okay, diese Queery kostet mich so und so viel. [SPEAKER_00]: Haben wir auch in den Schonuz verlinkt. [SPEAKER_00]: Ist ein sehr interessanter Artikel, auch wenn ihr als nicht grafkühl API es schreibt. [SPEAKER_00]: Ich hatte sehr viel Spaß in den Zulesen, einfach nur mal zu gucken, okay, wie machen die das sind? [SPEAKER_01]: Gelesen meist du mit wirklich duherst, den Gelesen oder du hast den nach GPD kopiert und zusammen etwasen lassen?

[SPEAKER_00]: Ich lasse mir kaum Texte von GPD zusammenfassen, weil besonders solche Sachen lees ich mir sehr, sehr gerne durch, weil ich möchte ja keine Teilgrad verlieren. [SPEAKER_00]: Okay, ich werde mir das heute als Gute Nachtleck-Türret zu gemütifieren. [SPEAKER_00]: Eine Sache, aber die man auch machen kann, ist man kann Persistentikvieries definieren. [SPEAKER_00]: Das bedeutet, das sind so nur vor abgenämmigte Queries, die man dann auf seiner API erlaubt.

[SPEAKER_00]: So mit hat man natürlich keine Adhock-Experimentier-Queries-Improduktion. [SPEAKER_00]: Ja, da ist der Feedback loope, sondern auch mit verschiedenen Teams natürlich länger, weil in der Regel hast du irgendwie ein Team, das macht eine GraphQL API und andere nutzt aus. [SPEAKER_00]: Und du willst natürlich nicht konzentriere Kommunikation ab? [SPEAKER_00]: Da hab ich diese Creepy-Senden.

[SPEAKER_00]: Aber kann man machen, so kontrolliert man so ein bisschen den, die Last auf der GraphQL API. [SPEAKER_01]: Es wird ja oft einfach als Security-Maßnahme gemacht, dass man wirklich nur vor definierte Chris absenden kann und wenn man sowohl selber wie auch client owned, als team ist es und durch sowieso kein Problem und teilweise wird es dann auch cross-compalliert, dass man die automatisch an dem client dazu verfügung hat oder überhaupt nur mit einer IT-referenziert hat.

[SPEAKER_01]: Also da gibt es Möglichkeiten dazu, wenn man billige vielleicht auch nicht die API so komplett aufmachen, dass jeder, der der Zugriff hat, auch wenn man angemeldet, der user ist, plötzlich auf alle Daten irgendwie zugreifen kann und es eins zu eins auf SQL dann umgesetzt wird oder [SPEAKER_01]: Das kann ja auch Security-Technisch doch aus dem Problem sein.

[SPEAKER_01]: Und nachdem wir heute schon ganz oft die vierte Wand durchbrochen haben, an die ganze die vierte Wand, es ist im Theater, wenn plötzlich die Theater Leute aus dem Stück aussteigen, Schauspieler heißen die, Schauspielterinnen, ja. [SPEAKER_01]: Wenn die aus dem Stück aussteigen und plötzlich auf so einer Meter Ebene mit dem Publikum sprechen und nicht mehr so tun, als weil es Publikum nicht existent, durchbricht man die vierte Wand.

[SPEAKER_01]: Und das haben wir heute auch schon gemacht, nachdem wir öfters über unsere Nots gesprochen haben, [SPEAKER_01]: Dann nächste Punkt, in unserem Skript, ist jetzt die Zusammenfassung. [SPEAKER_01]: Und Andy ist da der Spezialist darin, es ganze Thema noch mal in drei Sätzen zusammenzufassen, Andy, deine Bühne jetzt für die Zusammenfassung.

[SPEAKER_00]: Ich habe eigentlich gehofft, dass ich jetzt hier keine Zusammenfassung machen muss, sondern dass ich dich frage, was du vor der Episode von Red Limiting gehört hast und was du jetzt über Red Limiting denkst. [SPEAKER_00]: Weil du stehst diesen Team ja immer sehr skeptisch gegenüber sauerd. [SPEAKER_00]: Das kann ich da schon alles ist ja alles ganz einfach und so weiter und so fort. [SPEAKER_00]: Und es ist jedes Mal das gleiche mit dir.

[SPEAKER_00]: Als Berater ist man immer nur so hohe Level unterwegs, immer nur auf der Oberfläche, aber in den Mariannen Graben möchte du nie tauchen. [SPEAKER_01]: Ihr wird jetzt auch die Viertelwand noch mal durchbrechern und wird mir jetzt beschweren, dass da andisse ich nicht, dann uns das Kript halt, der dann unsere Struktur und mir jetzt einfach etwas auflegt, was kann ich zu uns ums Kript steht? [SPEAKER_00]: Es ist kript, hört sich ja gerade so an, als steht da jedes explizitivort.

[SPEAKER_00]: Natürlich hat unsere Episode eine gewisse Art von Vorbereitungen. [SPEAKER_01]: Ja, wir haben Freestyle so eigentlich nur durch. [SPEAKER_01]: Wir haben nur ein paar Schlagwerte, die uns da helfen zu Freestyle. [SPEAKER_01]: Aber ich bin ja auch gut im Freestyle, darum möchte ja deine Frage natürlich beantworten. [SPEAKER_01]: Was mir diese Episode gezeigt hat, ist eigentlich, dass sie auf der Kleinzeit schon meine Meinung nach ganz gut unterwegs bin.

[SPEAKER_01]: Aber ich muss zugeben, dass ich auf das Serverseite eigentlich nie an irgendein Redel mit den gedacht habe. [SPEAKER_01]: Und aber doch wie auch so in der Vorbereitung von dieser Episode drüber nachgedacht habe, dass ich schon einige Server Systeme hätte, wo das eigentlich sehr gut wäre,

[SPEAKER_01]: Und man hat ja Engine X oder so der Vorhängen, also man breuchte diese Option nur aktivieren und hätte dann wahrscheinlich am Ende mehr Resilienz im System und vielleicht auch glückliche Rekunden, weil man auch da zeigen kann, wie professionell mal ist und deshalb kommunizieren kann und dementsprechend auch besser auftreten kann am Markt.

[SPEAKER_01]: Also, es hat mir schon gezeigt, es ist noch Luft noch oben bei mir, es ist einfach zu implementieren, zumindest grundlegend mal und es ist auf jeden Fall Wert drüber nachzudenken. [SPEAKER_01]: Trüber nachzudenken, das ist, glaube ich, der größte Punkt, oder mein wichtiges Learning, dass man mal Trüber nachdenkt, was kann man eigentlich machen oder das besprecht im Team, was macht Sinn, könnte man da irgendwas einfach simplementieren.

[SPEAKER_00]: Ich glaube, eins der wichtigsten Elemente ist, dass das Rätelmeting nicht nur für große Server fahren oder ähnliches notwendig ist, sondern auch für Internet-Applikationen.

[SPEAKER_00]: Ich habe schon den etlichen Firmen gearbeitet, wo wir uns selbst intern abgeschossen haben und dann nicht wussten, woher kommt die Riequist und wer hammer darauf rum und dann war das irgendein Entwickler, der irgendwas auf dem Lettop Laufen hatte und dann das ganze ist sehr mit runtergezogen, hat und da hätte uns einen simpleren Rät limit Algorithmus halt auch geholfen, deswegen ist meines Erachtens noch nicht optional, sondern fundamental, speziell in den Fällen, wo man interner APIs irgendwie anbietet.

[SPEAKER_00]: Also, merkt euch eins, der Schlusssatz, den habe ich mir extra jetzt generieren lassen. [SPEAKER_00]: Eine Resilient-System sagt auch mal bewusst nein und bleibt deshalb erreichbar. [SPEAKER_00]: Das war das Wort zum Sonntag von mir. [SPEAKER_01]: Das ist fast leurisch, ja. [SPEAKER_00]: Ich hoffe, ihr hatte ein bisschen Spaß und habt die ein oder andere bei dem Thema Raidlimiting mitgenommen, um die ganze Sache noch mal kompliziert zu machen.

[SPEAKER_00]: Bitte verwechselt, Radelimiting, also nicht mit Backpressure, Graceful, Degradation oder Fault-Asulation. [SPEAKER_00]: Aber verwechselt es auch nicht mit Load-Shading. [SPEAKER_00]: Was ist der Load-Shading jetzt schon wieder? [SPEAKER_00]: Ja, dieses Thema mit Resilius Engineering, das geht immer und immer und immer weiter. [SPEAKER_00]: Das war's von uns. [SPEAKER_01]: Jetzt musst du schon laut Schädding erklären.

[SPEAKER_01]: Wenn du schon neues Walter mit einstreust, das ist, sorry, dass ihr die dahinter dazu zusammenfassung jetzt unterbrechen musst. [SPEAKER_01]: Jetzt musst du jetzt in einem Satz schon erklären. [SPEAKER_01]: Also du sagst, wir machen die nächste Episode nur über laut Schädding, aber da hätte ich wirklich etwas dagegen. [SPEAKER_00]: Das könnte als T-Sire sein, bis ich dich dann überzeugt habe. [SPEAKER_00]: Wir haben aber Backpressure gesprochen.

[SPEAKER_00]: Backpressure ist da, kommt ganz viel Treffek auf ein System. [SPEAKER_00]: Und Back-Dass System, was in Treffek akzeptiert, sagt nach oben. [SPEAKER_00]: Egolege, ich kriege ein bisschen viel Treffek, mach mal langsamer. [SPEAKER_00]: Load-Shading ist ein System kriegt ganz viel Treffek. [SPEAKER_00]: Und arbeitet das so weit ab wie möglich. [SPEAKER_00]: Und irgendwann sagt das System immer jetzt bin ich überladen.

[SPEAKER_00]: Sagt dem Absprieben System, aber ich beschleit so nun verwirft den zusätzlichen Treffek einfach. [SPEAKER_00]: Bedeutelt also, load-sharing passiert reagativ, rate-limiting, proaktiv, sind alles so dynamisch, faltenes Systeme und, ja, gibt es halt immer Fachbegriffe. [SPEAKER_00]: Und wir haben mal gar nicht über Gravell, ja, so der Ähnliches ist gesprochen, aber das lassen wir jetzt auch weg. [SPEAKER_00]: Weil irgendwas müssen wir in den nächsten Episode her noch mal besprechen.

[SPEAKER_00]: Der war früher ein Grins jetzt wieder, weil der denkt sich schöner Brower, jetzt kommt der nächsten Monate wieder mit so einer IP-Soda. [SPEAKER_01]: immer diese Resilience Episode. [SPEAKER_01]: Aber lass uns mal wissen, was hier von den Resilience Episode so denkt, ganz allgemein natürlich, aber auch ob ihr rettle mit den implementiert habt, ob ihr irgendeine Library verwendet, schättes gerne bei uns im Discord.

[SPEAKER_01]: Da haben alle dann was davon, wenn man auch aus der Praxis mal hört, was so im Einsatz ist, ein Tools oder welche Möglichkeit man da hat. [SPEAKER_00]: So, jetzt habe ich auch mit klugscheißen und den Basswort bingen und roten. [SPEAKER_01]: Ich bin raus für uns nächste Woche da. [UNKNOWN]: Bis bald, tschüss. [UNKNOWN]: Ciao.