Sie benötigen einen serverseitigen Cache, haben zwei Vergleichsseiten gelesen und beide sagen: „Es kommt darauf an.“ Sehr hilfreich. Klären wir die Frage Redis vs. Memcached also direkt: Memcached ist die bessere Wahl, wenn Sie einen einfachen, schnellen Cache ohne Zusatzfunktionen suchen. Redis ist die bessere Wahl, wenn der Cache strukturierte Daten speichern, einen Neustart überstehen oder Ihrer Anwendung Arbeit abnehmen soll.
Sowohl Redis als auch Memcached sind:
Bei dieser gemeinsamen Liste hören die meisten Artikel auf. Dieser hier geht weiter, denn die interessanten Unterschiede beginnen erst danach.
Beide speichern Daten im Arbeitsspeicher, um Anwendungen zu beschleunigen. Sie sind jedoch für unterschiedliche Anwendungsbereiche konzipiert.
Memcached ist einfach gehalten. Es bietet eine grundlegende Key-Value-Speicherung und zeichnet sich durch schnelles Caching aus, was vor allem an seiner Multithreading-Performance liegt.
Redis unterstützt komplexere Datentypen und eine dauerhafte Datenspeicherung, wodurch es vielseitiger für Aufgaben wie Messaging und Sitzungsverwaltung einsetzbar ist. Zudem bietet es erweiterte Funktionen wie Data Sharding, bei dem ein Datensatz auf mehrere Server verteilt wird, damit kein einzelner Rechner die gesamte Last trägt, sowie eine Auswahl an verschiedenen Eviction-Richtlinien.
Basierend auf einem Kundenprojekt werde ich erläutern, wie die beiden Systeme mit Datenspeicherung und Skalierbarkeit umgehen und welches in welchen Szenarien besser abschneidet. Zuerst die Grundlagen.
Redis, kurz für Remote Dictionary Server, wurde 2009 von Salvatore Sanfilippo entwickelt, um die Skalierbarkeit des Web-Log-Analysators zu verbessern, an dem sein italienisches Startup arbeitete. Der erste Prototyp wurde in Tcl geschrieben und später in C übertragen. Als Sanfilippo das Projekt als Open Source veröffentlichte, gewann es schnell an Bedeutung. GitHub und Instagram gehörten zu den ersten Unternehmen, die es einsetzten, und die Dokumentation des Projekts gilt bis heute als Referenz für dessen Funktionsweise und Grenzen.
Memcached kam etwas früher, im Jahr 2003, auf den Markt und wurde von Brad Fitzpatrick für seine Website LiveJournal entwickelt. Es wurde ursprünglich in Perl geschrieben und später in C übersetzt. Einige der weltweit größten Unternehmen, darunter Facebook, YouTube und Twitter, setzen es ein. Die Funktionsweise ist im Memcached-Wiki dokumentiert.
Redis ist eigentlich kein Key-Value-Store, sondern ein Server für Datenstrukturen. Die fünf wichtigsten sind:
Darüber hinaus bietet es Bitmaps, Bitfields, HyperLogLogs (probabilistische Kardinalitätszähler) und geospatiale Indizes sowie Streams für Append-only-Logs. JSON, Querying, Zeitreihen und – ab Redis 8 – Vektor-Sets werden über Module eingebunden (Dokumentation zu Redis-Datentypen). Das geht weit über „Keys und Strings“ hinaus, und genau diese Vielfalt ist der Grund, warum Redis dort eingesetzt wird, wo ein einfacher Cache nicht mehr ausreicht.
Redis unterstützt Operationen auf Datentypen. Das bedeutet, Sie können Teile eines Objekts lesen oder ändern, ohne das gesamte Objekt in Ihre Anwendung laden, bearbeiten und wieder speichern zu müssen.
Für die Speicherverwaltung nutzt es eine gekapselte Version von malloc/free, dem Standard-C-Mechanismus zum Anfordern und Freigeben von Speicher. Das ist einfacher als der Memcached-Slab-Mechanismus, auf den ich gleich noch eingehe.
Keys können bis zu 512 MB groß sein, ebenso wie Values, wie in der Dokumentation zu Datentypen festgelegtBei aggregierten Datentypen wie Listen und Sets gilt dieses Limit pro Element.
Memcached kennt keine Datentypen. Es speichert Strings, die über einen String-Schlüssel indiziert werden, und benötigt dafür weniger Speicher-Overhead als Redis.
Zudem ist es durch den Arbeitsspeicher der Maschine begrenzt, auf der es läuft. Wenn dieser voll ist, beginnt es, Werte nach dem Prinzip „Least Recently Used“ zu löschen. Sein Zuweisungsmechanismus, Slab, unterteilt den Speicher in Blöcke unterschiedlicher Größe und speichert jeden Key-Value-Datensatz in dem passenden Block. Dies verhindert, dass der Speicher in zu kleine, nicht mehr nutzbare Lücken fragmentiert.
Schlüssel sind auf 250 Byte und Werte auf 1 MB begrenzt. Dies sind jedoch Standardwerte; die maximale Slab-Größe kann beim Start erhöht werden (siehe das Memcached-Wiki).
Stellen Sie sich ein zwischengespeichertes Objekt wie einen Mantel in einer Garderobe vor. Bei Memcached können Sie nur den gesamten Mantel abholen: Um den Inhalt einer Tasche zu ändern, muss der String geladen, deserialisiert, das Feld bearbeitet, serialisiert und wieder gespeichert werden.
Redis erlaubt Ihnen den direkten Zugriff auf die Tasche. Der Hash-Datentyp ermöglicht den Zugriff auf jedes Feld einzeln, sodass jede CRUD-Operation (Create, Read, Update, Delete) nur auf dieses Feld angewendet wird. Ein einziger Netzwerk-Roundtrip, der etwa so viel kostet wie ein einfaches Get oder Set, ersetzt vier Austauschvorgänge und zwei Serialisierungsschritte.
Hier ist das gleiche Sitzungs-Update auf beide Arten:
# Memcached — the whole session object is the unit of work
value = mc.get("session:42") # 1. fetch the whole blob
session = deserialise(value) # 2. deserialise in app memory
session["last_seen"] = now() # 3. edit one field
mc.set("session:42", serialise(session)) # 4. serialise + write it all back
# → 2 network round trips, 2 (de)serialisation steps, in your app code
# Redis — the field is the unit of work
HSET session:42 last_seen <now> # one round trip, no (de)serialisation
# → the read-modify-write collapses into a single command on the serverDer Grund, warum dies funktioniert, ist nicht spezifisch für unser Projekt. Die Dokumentation von Redis und unabhängige Benchmarks zeigen, dass die Reduzierung von Netzwerk-Roundtrips – statt der Beschleunigung einzelner Befehle – den Durchsatz maßgeblich steigert. Die entsprechenden Zahlen finden Sie im Abschnitt zur Performance weiter unten.
Redis ist überwiegend Single-Threaded, das heißt, ein einzelner Kern führt die Befehle aus, unabhängig davon, wie viele Kerne der Rechner besitzt. (Threaded I/O wurde mit Redis 6 eingeführt, und Redis 8 sowie der Valkey-Fork haben das I/O-Multithreading weiter vorangetrieben – die Befehle selbst laufen jedoch weiterhin auf einem einzigen Thread; AWS weist in seinem auf dieselbe Unterscheidung zwischen Single-Threading und I/O-Multithreading hin.) ElastiCache-Engine-VergleichDank nativer Clustering-Unterstützung skaliert es stattdessen hervorragend horizontal.
Das Clustering basiert auf einer Master/Slave-Architektur, bei der ein Knoten Schreibvorgänge entgegennimmt, während die anderen Kopien seiner Daten vorhalten. Jeder Master verfügt zur Redundanz über zwei Slaves, sodass das System bei einem Ausfall des Masters automatisch einen davon hochstuft. Der Preis dafür ist der Wartungsaufwand: Mehrere synchron laufende Knoten sind schwieriger fehlerfrei zu halten als ein einzelner.
Memcached skaliert problemlos vertikal, da es Multithreading unterstützt. Geben Sie ihm mehr Kerne und mehr Arbeitsspeicher, und die Aufgabe ist erledigt.
Es skaliert auch horizontal, und zwar auf Client-Seite durch einen von Ihnen implementierten verteilten Algorithmus. Das ist mit mehr Aufwand verbunden als bei Redis, das Clustering direkt ab Werk mitliefert.
Der größte Unterschied zwischen beiden besteht darin, was einen Neustart überlebt. Redis ist ein (größtenteils) In-Memory-Datenspeicher und nicht flüchtig. Memcached ist ein In-Memory-Cache und flüchtig: Startet man den Prozess neu, sind die Inhalte gelöscht.
Redis unterstützt Persistenz – weshalb es als Datenspeicher bezeichnet wird – auf zwei Arten (Redis-Dokumentation zur Persistenz):
Ein Kindprozess kümmert sich um diese Dateien, und dieses Detail entscheidet darüber, welche Methode Sie wählen sollten.
Ist ein großer Datensatz ein Problem? Für RDB: ja. Die Erstellung der Datei nimmt Zeit in Anspruch, was sich in den Antwortzeiten niederschlägt, obwohl sie beim Booten schneller geladen wird als das AOF-Log.
Wählen Sie AOF, wenn Datenverlust absolut inakzeptabel ist. Es kann bei jedem Befehl aktualisiert werden und weist aufgrund der Append-Only-Struktur keine Korruptionsprobleme auf. Es wird jedoch deutlich größer als ein RDB-Snapshot.
Nichts, das ist so beabsichtigt. Kein Snapshot, kein Log. Ein Neustart, ein Absturz oder ein Failover führt zu einem leeren Cache, und die erste Welle von Anfragen danach geht direkt an die Datenbank durch.
Das ist in Ordnung, wenn der Cache abgeleitete Daten enthält, die kostengünstig neu berechnet werden können. Wenn das nicht der Fall ist, wird es zu einem Problem der Kapazitätsplanung.
Memcached ist auf die LRU-Eviction-Strategie (Least Recently Used) beschränkt, während Redis acht unterstützt (Redis-Dokumentation zur Key-Eviction):
Was Sie damit gewinnen, ist Kontrolle. Bei Memcached entscheidet die LRU-Strategie und Sie müssen damit leben. Bei Redis können Sie Schlüssel schützen, die nicht gelöscht werden dürfen, und alles andere drumherum räumen lassen.
An dieser Stelle ersetzen Vergleichsseiten meist Fakten durch Behauptungen. Wir lassen stattdessen Zahlen sprechen.
Redis veröffentlicht eigene Durchsatzdaten. Die Benchmark-Dokumentation berichtet, dass ein Linux-Server der Einstiegsklasse mit einer einzelnen Redis-Instanz bei kleinen Payloads etwa 100.000 Anfragen pro Sekunde bei einer Latenz im Sub-Millisekundenbereich in einem lokalen Netzwerk verarbeitet. Diese Obergrenze gilt für einen Kern. Da die Befehlsausführung Single-Threaded erfolgt, lässt sie sich nicht durch das Hinzufügen weiterer Kerne steigern. Redis 6 hat zwar Threaded I/O eingeführt, um Socket-Lese- und Schreibvorgänge zu parallelisieren, aber die Befehle selbst laufen weiterhin auf einem einzigen Thread.
Memcached ist durchgehend Multithreaded, sodass der Durchsatz mit der Anzahl der Kerne steigt, bis die Netzwerkschnittstelle ausgelastet ist. Das ist der einzige Leistungsvorteil, der jedoch ein echter ist: Auf einer Multi-Core-Maschine, die große, einfache Werte bereitstellt, bewegt Memcached mehr Daten pro Sekunde als ein einzelner Redis-Prozess. Deshalb dokumentiert AWS beide unterschiedlich, selbst innerhalb desselben Managed Service – das eigene Whitepaper merkt an, dass Memcached „größere [Instanz-]Größen mit mehreren Kernen gut nutzt“, während Redis eher wie eine zustandsbehaftete Datenbank verwaltet wird (Memcached vs. Redis: Performance at Scale with Amazon ElastiCache).
Zwei Einschränkungen sind wichtiger als die reinen Zahlen. Erstens besteht eine Redis-Bereitstellung selten aus nur einem Prozess; Sharding über Instanzen hinweg holt den Multi-Core-Vorteil zurück, allerdings auf Kosten des Cluster-Wartungsaufwands. Zweitens sind Operationen pro Sekunde der falsche Maßstab, wenn ein einziger Redis-Befehl mehrere Roundtrips der Anwendung ersetzt. Ein Hash-Feld-Update ist ein einzelner Netzwerkaustausch, während Memcached dafür ein Lesen, eine Deserialisierung, ein Schreiben und eine Serialisierung benötigt. Redis kann pro Operation langsamer sein und dennoch als Erster fertig werden.
Das ist nicht nur unsere eigene Erfahrung; der Mechanismus ist dokumentiert und messbar. Da jeder Befehl einen Netzwerk-Roundtrip erfordert, ist es die Roundtrip-Zeit – nicht die Befehlsausführung –, die den Durchsatz normalerweise begrenzt. Der eigene Pipelining-Leitfaden von Redis macht dies deutlich: Bei einer Verbindung mit 250 ms Roundtrip-Zeit wird ein Server, der eigentlich 100.000 Anfragen pro Sekunde verarbeiten könnte, auf etwa vier pro Sekunde gedrosselt, solange man für jeden Befehl einen Roundtrip bezahlt. Unabhängige Benchmarks zeigen das Potenzial: In einem häufig zitierten Testlauf auf der DigitalOcean-Infrastruktursteigerte das Zusammenfassen von Roundtrips einen Standard- redis-benchmark von etwa 97.000 GET/s auf rund 1,35 Millionen GET/s – ein Gewinn von ca. 14x, der allein durch die Reduzierung der Netzwerkaustausche erzielt wurde, nicht durch schnellere Befehle. Das ist derselbe Hebel, den unsere Änderung am Session-Objekt in anderer Form betätigt hat: ein Hash-Befehl anstelle von Lesen, Deserialisieren, Bearbeiten, Serialisieren und Schreiben. (Pipelining fasst viele Befehle zusammen; der Hash-Typ fasst ein Read-Modify-Write zusammen – unterschiedliche Techniken, identisches Prinzip: weniger Fahrten über die Leitung.)
Die Regel lautet also: Memcached für ein hohes Volumen an unabhängigen Lesezugriffen auf ganze Werte auf einer großen Maschine. Redis dort, wo die Struktur der Daten es erlaubt, weniger und intelligentere Operationen durchzuführen.
Drei Situationen rechtfertigen den operativen Aufwand, und sie haben eines gemeinsam: Der Cache übernimmt Aufgaben, die sonst Ihre Anwendungsserver erledigen müssten.
Memcached eignet sich, wenn der Cache tatsächlich ein Cache ist: Werte werden als Ganzes geschrieben, als Ganzes gelesen und ihr Verlust ist unkritisch.
Hier ist der Punkt, der es selten auf eine Vergleichsseite schafft. Wir nennen ihn den Exit-Kosten-Test: Bevor Sie sich für einen Cache entscheiden, fragen Sie sich, was es kosten würde, ihn wieder zu verlassen. Die beiden Antworten sind nicht symmetrisch.
Bei Imaginary Cloud haben wir beide in vielen verschiedenen Kundenprojekten eingesetzt. Bei einem Projekt, an dem ich beteiligt war, mussten wir uns zwischen beiden entscheiden. Wir begannen mit Memcached wegen seiner Einfachheit, Benutzerfreundlichkeit und leichten Einrichtung, und weil wir einfach einen Cache brauchten, Persistenz also keine Anforderung war. Nach einigen Tests wechselten wir zu Redis, um von den Vorteilen der Datentypen zu profitieren.
Die Datentyp-Operationen passten zu der Art von Daten, die wir speicherten. Redis bietet zudem einen Befehl zum Suchen von Schlüsseln, die einem Muster entsprechen, sowie viele weitere Befehle für die Arbeit mit Schlüsseln – und genau diese Funktion haben wir immer wieder genutzt. Das war der entscheidende Faktor für die Migration.
Die Migration selbst war unkompliziert, da Redis die meisten Befehle von Memcached unterstützt. Client umstellen, Cache neu füllen lassen, weiterarbeiten.
Der umgekehrte Weg ist eine andere Geschichte. Memcached kennt keine Datentypen, daher muss jeder Redis-Datentyp-Befehl in mehrere Memcached-Befehle übersetzt werden, wobei dazwischen eine Datenverarbeitung stattfinden muss, um das gleiche Ergebnis zu erzielen. Diese Logik landet dann wieder im Anwendungscode, aus dem Sie sie eigentlich herausgelöst hatten.
Diese Asymmetrie ist der Test. Beginnen Sie mit Memcached, bleibt Ihnen ein günstiger Ausstieg zu Redis. Beginnen Sie mit Redis und stellen fest, dass Sie eigentlich nur einen einfachen Cache benötigt hätten, müssen Sie die Anwendungslogik umschreiben, um zurückzukehren. Wenn die Anforderungen wirklich unsicher sind, sollten die Exit-Kosten schwerer wiegen als jeder Benchmark.
Redis ist flexibler und leistungsfähiger. Memcached erfüllt jedoch nach wie vor bestimmte Zwecke sehr gut und ist in manchen Fällen sogar schneller, da sich Multithreading auszahlt, wenn große Mengen einfacher Daten verarbeitet werden.
Redis unterstützt Datenoperationen durch seine Datentypen, wodurch sowohl die Anzahl der Netzwerk-I/O-Vorgänge als auch die übertragenen Datenmengen reduziert werden. Ein Update eines Hash-Feldes kostet in etwa so viel wie ein einfacher Get- oder Set-Befehl, sodass die Arbeit in Ihrer Anwendung erledigt wird, ohne zusätzliche Zeit bei der Übertragung zu beanspruchen.
Gibt es also einen Gewinner? Nein, natürlich nicht. Wenden Sie die Leistungsregel an und führen Sie anschließend den Exit-Cost-Test durch. Memcached eignet sich für ein hohes Volumen an unabhängigen Lesezugriffen auf vollständige Werte auf einer großen Maschine. Redis ist die richtige Wahl, wenn die Struktur der Daten intelligentere und weniger Operationen ermöglicht. Wenn beide Optionen nah beieinander liegen, wählen Sie diejenige, bei der ein späterer Wechsel kostengünstiger wäre. Unserer Erfahrung nach erspart Ihnen das Abwägen dieser Vor- und Nachteile zu Beginn eine Migration mitten im Projekt.
Wenn Sie die Architektur absegnen, anstatt sie selbst zu schreiben, reduziert sich der technische Vergleich auf drei kommerzielle Fragen. Wir wenden diese auf jede Infrastruktur- und Stack-Entscheidungan, nicht nur auf Caching.
1. Was kostet der Betrieb? Memcached hat einen geringeren Speicher-Overhead pro Element, sodass das gleiche Working Set in eine kleinere Instanz passt. Redis kostet pro zwischengespeichertem Gigabyte mehr, sobald Persistenz und Replikation aktiviert sind, da ein RDB-Snapshot Spielraum für den geforkten Kindprozess benötigt und ein replizierter Cluster die Anzahl der Instanzen vervielfacht. Bei wenigen Gigabyte ist der Unterschied gering. Bei einigen hundert Gigabyte wird er jedoch erheblich.
2. Wer ist am Montagmorgen dafür verantwortlich? Eine einzelne Memcached-Instanz erfordert nahezu keinen Wartungsaufwand. Ein Redis-Cluster mit Master- und Replica-Nodes, Failover und Persistenz-Tuning ist ein System, für das jemand die Verantwortung übernehmen muss: Überwachung, Testen des Failovers, Dimensionierung des Snapshot-Fensters. Wenn es niemanden in Ihrem Team gibt, der das übernimmt, sind die ehrlichen Optionen ein Managed Service oder Memcached. ElastiCache oder MemoryDB verlagern die Arbeit zum Anbieter und stellen sie in Rechnung, was für ein kleines Team meist der richtige Kompromiss ist.
3. Wie sieht es mit Lizenzierung und Kontinuität aus? Im März 2024 wechselte Redis von der BSD-Lizenz zu einem Source-Available-Dual-Modell (RSALv2 und SSPLv1), was die Linux Foundation dazu veranlasste, das letzte BSD-Release (7.2.4) als Valkeyzu forken. Im Mai 2025 fügte Redis 8 neben den Source-Available-Optionen die AGPLv3 hinzu – eine OSI-konforme Open-Source-Lizenz –, sodass Redis nun wieder unter einer Dreifach-Lizenz ausgeliefert wird und Salvatore Sanfilippo bereits im Jahr zuvor zum Unternehmen zurückgekehrt war. Der Fork blieb dennoch bestehen: AWS selbst weist darauf hin, dass die Redis 8.0 Community Edition unter AGPLv3 steht (eine Copyleft-Lizenz, die viele Unternehmen untersagen), während Memcached bei BSD bleibt, und empfiehlt nun Valkey für neue ElastiCache-Workloads (AWS: Vergleich von Redis und Memcached). Diese Episode erinnert daran, dass Redis eine Abhängigkeit mit einem kommerziellen Eigentümer ist und eine Lizenz besitzt, die sich unter Druck bereits geändert hat. Memcached ist durchgehend BSD geblieben und hat eine solche Historie nicht. Für die meisten Teams ist das kein Hindernis. Für alle, die einen Cache in ein Produkt einbetten, das sie weitervertreiben – wo die AGPL-Copyleft-Klausel greift –, ist dies eine Frage, die vor dem Schreiben des Codes geklärt werden muss, und Valkey ist der permissive Ausweg, den man kennen sollte.
Die Time-to-Value spricht meist dafür, einfach zu starten. Memcached ist schneller aufgesetzt, und wie der Exit-Kosten-Test zeigt, ist ein späterer Wechsel zu Redis kostengünstig. Umgekehrt ist dies nicht der Fall.
Nicht pauschal. Bei kleinen Werten liegen beide pro Operation nah beieinander; Redis erreicht auf Einstiegshardware etwa 100.000 Anfragen pro Sekunde für eine einzelne Instanz. Da Memcached multithreaded arbeitet, kann es auf Systemen mit vielen Kernen bei großen, einfachen Werten mehr Daten pro Sekunde verarbeiten. Redis punktet dort, wo seine Datentypen mehrere Roundtrips der Anwendung durch einen einzigen Befehl ersetzen.
Ja, wenn es tatsächlich nur um Caching geht. Für flüchtige Daten, einfache Werte, ohne die Notwendigkeit von Persistenz und bei ausreichend verfügbaren CPU-Kernen ist Memcached einfacher zu betreiben, verbraucht weniger Arbeitsspeicher und bietet kaum Angriffsfläche für den Betrieb.
Ja, und das ist die einfachere Richtung – genau das ist der Kern des Exit-Cost-Tests. Redis unterstützt die meisten Memcached-Befehle, sodass man in der Praxis lediglich den Client umstellen muss und den Cache neu befüllt. Der umgekehrte Weg erfordert hingegen, Datentyp-Operationen in mehrere Memcached-Befehle sowie zusätzliche Logik auf Anwendungsebene umzuschreiben.
Nein. Memcached ist ein flüchtiger In-Memory-Cache: Nach einem Neustart sind die Daten verloren. Redis bietet Persistenz durch RDB-Snapshots, also Point-in-Time-Dumps auf die Festplatte, oder durch ein AOF-Log, das beim Start jeden Schreibbefehl erneut ausführt.
Memcached ist bei den Infrastrukturkosten meist günstiger, da der Speicher-Overhead pro Element geringer ist und die Verwaltung einer einzelnen Instanz einfacher ausfällt. Redis verursacht in der Regel höhere Kosten, sobald Replikation und Persistenz aktiviert werden. Die Rechnung ändert sich jedoch, wenn Redis die Last von Ihren Anwendungsservern oder Ihrer Datenbank nimmt, da diese Einsparungen die Differenz bei den Cache-Kosten überwiegen können.
Redis unterstützt Clustering nativ mit Master- und Replica-Knoten sowie automatischem Failover. Memcached verteilt Daten clientseitig mithilfe eines Sharding-Algorithmus, den Sie selbst implementieren müssen. Managed Services bieten beides an – und bei neuen Bereitstellungen setzen ElastiCache und Memorystore mittlerweile standardmäßig auf den BSD-lizenzierten Valkey-Fork, was für Teams ohne dedizierten Platform Engineer in der Regel die sinnvollere Wahl ist.
Zunehmend ja – das ist der Grund, warum dieser Vergleich seit 2024 einen dritten Namen enthält. Valkey ist der von der Linux Foundation verwaltete, BSD-lizenzierte Fork von Redis 7.2.4. Er ist API-kompatibel und mittlerweile der Standard bei den großen Managed Services. Wenn Ihre einzige Sorge bei Redis die Lizenz ist, beseitigt Valkey diese Hürde, ohne dass Sie Ihre Anbindung an den Cache ändern müssen.
Sie entscheiden, auf welchem Cache Ihre Architektur basieren soll? Wir unterstützen Engineering-Teams dabei, Infrastruktur zu wählen, die sie sich nicht nur leisten können, sondern die sie später auch ohne hohe Kosten austauschen können. Sprechen Sie mit unserem Team darüber, wohin sich Ihr System entwickelt.
Webentwickler bei Imaginary Cloud, der von Node.js und allem, was mit Backend-Entwicklung zu tun hat, begeistert ist.
CEO von Imaginary Cloud und Mitautor des Buches Product Design Process. Ich mag Essen, Wein und Krav Maga (nicht unbedingt in dieser Reihenfolge).
People who read this post, also found these interesting:
.webp)
