Wat we ermee bouwen
NATS is hoe services met elkaar praten zonder van elkaar te weten. Een service publiceert dat er iets is gebeurd; welke services dat aangaat, abonneren zich. Niets in de code van de publicerende kant hoeft te veranderen als er een nieuwe afnemer bij komt, en juist die eigenschap voorkomt dat een systeem een web van directe HTTP-aanroepen tussen alles wordt.
Het doet ook request/reply, dus het kan HTTP tussen services vervangen waar je routering en herhaalpogingen liever voor je laat afhandelen dan in elke client opnieuw te bouwen.
Waar het past
Tussen backendservices, naast Go — realtime fan-out, gebeurtenismeldingen, en het loskoppelen van wat een gebeurtenis vastlegt van wat erop reageert.
De reden dat we juist naar NATS grijpen is het beheergewicht. Het is één kleine binary met een eenvoudige configuratie, en dat is een heel andere verplichting dan een volledig brokercluster draaien en afstemmen voor een systeem dat er nog geen nodig heeft.
Wanneer we het aanraden
Wanneer je meer dan een paar services hebt en ze elkaar rechtstreeks beginnen aan te roepen, of wanneer je gebeurtenissen moet afleveren bij een groep afnemers die gaat groeien.
Niet voor een product met één service — een wachtrij in het proces of Redis is minder om te draaien en doet het werk. En heb je langdurige, duurzame gebeurtenisopslag nodig met herafspelen over lange bewaartermijnen, dan past een loggeoriënteerd systeem beter; NATS met JetStream dekt daar veel van, maar kies het bewust en niet standaard.