Microservices architecture on Kubernetes
A Kubernetes microservices architecture with NGINX ingress, an API gateway, four bounded-context services (Users, Billing, Orders, Notifications), Postgres per service, Kafka for events, and an OpenTelemetry collector for observability.
Architecture previewMicroservices architecture on Kubernetes
Recreate this in Raltey
Copy this prompt
Paste this into Raltey's AI agent to generate the same diagram, then tweak it on the canvas.
Prompt
Create a Kubernetes microservices architecture. NGINX ingress routes to an API gateway, which fans out to four services: Users, Billing, Orders, Notifications. Each service has its own Postgres database (no shared DB). Orders and Billing publish events to Kafka; Notifications consumes them. Billing also talks to Stripe externally. All services export traces and metrics to an OpenTelemetry collector.
Context
- - Bounded contexts: Users, Billing, Orders, Notifications.
- - Postgres per service (no shared DB).
- - Kafka for async events between services.
- - Observability via OpenTelemetry to a central backend.
Patterns
- - Bounded contexts, each owning their data.
- - API gateway as the only public entry point.
- - Kafka topics decouple services (event-driven).
- - Sidecarless OpenTelemetry for tracing and metrics.
Diagram structure
Nodes and connections
Nodes
Client appactor
Stripeexternal
edge
NGINX Ingresslb
API Gatewayservice
services
Users serviceservice
Billing serviceservice
Orders serviceservice
Notifications serviceservice
data
Postgres (Users)db
Postgres (Billing)db
Postgres (Orders)db
Postgres (Notifs)db
Kafkaqueue
observability
OpenTelemetry collectorservice
Connections
Client appNGINX Ingress
NGINX IngressAPI Gateway
API GatewayUsers service
API GatewayBilling service
API GatewayOrders service
Users servicePostgres (Users)
Billing servicePostgres (Billing)
Billing serviceStripe
Orders servicePostgres (Orders)
Notifications servicePostgres (Notifs)
Orders serviceKafkaOrderCreated
Billing serviceKafkaPaymentSucceeded
KafkaNotifications service
Users serviceOpenTelemetry collector
Billing serviceOpenTelemetry collector
Orders serviceOpenTelemetry collector
Notifications serviceOpenTelemetry collector
Notes from the field
- No shared databases: each service owns its schema and reads via APIs or events.
- Use schema-registry for Kafka events to avoid breaking consumers.
- mTLS between services within the cluster (mesh or NetworkPolicies).
Frequently asked
Why one Postgres per service?
Sharing a DB across services makes refactoring and scaling miserable. Per-service ownership lets each team move independently.
When is Kafka overkill?
For fewer than five services with low cross-service event volume, NATS or even direct synchronous calls are simpler. Reach for Kafka when ordering, replay, and high throughput matter.
More templates
FlowchartSaaS onboarding email flowFlowchartCustomer support runbook flowFlowchartPayment webhook retry and error flowFlowchartGitHub PR review and merge flowFlowchartLogin with magic link flowArchitectureThree-tier SaaS architecture on AWSArchitectureReal-time data pipeline on GCPArchitectureNext.js + Vercel + Postgres SaaS stack
Open this template in Raltey
Edit it on the canvas, ask the AI agent to extend it, then share or export.
Start for free