kalix gradient

How Kalix Works

Easily build Self-Provisioning, Reactive Systems.

Developer Responsibility

Developer Experience

1
Design Kalix Service

Design Kalix Service

2
Kickstart Kalix Development Project

Kickstart Kalix Development Project

3
Describe Data Structures

Describe Data Structures

4
Define API

Define API

5
Implement Business Logic

Implement Business Logic

6
Test

Test

7
Run Locally in a Prod-like Environment

Run Locally in a Prod-like Environment

See Developer Sandboxes below
8
Deploy and Run on Kalix Platform on the Cloud provider of your choice

Deploy and Run on Kalix Platform on the Cloud provider of your choice

Explore Kalix

Want to go deeper? Explore Kalix will guide you through each step with specific use cases and code examples.

Developer Sandboxes (Coming Soon)

Developer Sandboxes is a pre-configured production-like local runtime that allows developers to test their changes as they code, which dramatically reduces the risk of things not working in production.

Integrate your Local Tools

Integrate your Local Tools

Run Locally in a Prod-Like Env

Run Locally in a Prod-Like Env

Test Locally in a Prod-Like Env

Test Locally in a Prod-Like Env

Developer Responsibility

Code

Let’s look at a Service consisting of Entity and View

Entity (Stateful)

API endpoint with:

  • Domain Data
  • Business Logic
  • HTTP definition
@EntityType("customer")
public class CustomerEntity extends ValueEntity<CustomerEntity.Customer> {

  record Customer(String name, String email) {}
  record CreateCustomer(String name, String email) {}
  
  @EntityKey("customer_id")
  @PostMapping("/customers/{customer_id}")
  public Effect<String> createCustomer(@RequestBody CreateCustomer create) {
    return effects()
      .updateState(new Customer(create.name, create.email))
      .thenReply("done");
  }
}

View (Materialized)

API endpoint:

  • Querying the domain data
  • Returning streamed data set
  • HTTP definition
@Table("customers")
@Subscribe.ValueEntity(CustomerEntity.class)
public class CustomerByNameView extends View<CustomerEntity.Customer> {
  
  @GetMapping("/customers/by-name/{name}")
  @Query("SELECT * FROM customers WHERE name = :name")
  public Flux<CustomerEntity.Customer> findCustomers(String name) {
      return null;
  }
}

NO CODE required for data persistence and query. The data is automatically injected into your services on an as-needed basis, and queries are consumed through live materialized views.

Operator Responsibility

Operator Experience

Kalix Tools: CLI and Web Console

Kalix Tools: CLI and Web Console

Manage Cloud and Edge Regions

Manage Cloud and Edge Regions

View Metrics, Logs, Service Health

View Metrics, Logs, Service Health

Integrate Events, Metrics, Logs with External Systems

Integrate Events, Metrics, Logs with External Systems

Manage Secrets, JWT, and Client Certificates

Manage Secrets, JWT, and Client Certificates

Manage Roles, Users, Organizations

Manage Roles, Users, Organizations

Manage Public APIs: Routes etc

Manage Public APIs: Routes etc

Manage Paid Plans

Manage Paid Plans

Developer Responsibility

Operator Responsibility

Managed by Kalix

Managed by Kalix

kalix gradient

Inferred from Code

Managed By Kalix

Auto-Generated Reactive Architecture

Auto Generated Reactive Architecture

Managed By Kalix

Unparalleled Performance

6 ms Read & 8 ms Write Latency

6 ms Read & 8 ms Write Latency

99.9% Uptime SLA

99.9% Uptime SLA

3x Faster Software Development

3x Faster Software Development

80% Reduced Operations Costs

80% Reduced Operations Costs

Low Latency with High Throughput

1000 TPS
99 percentile
8000 TPS
99 percentile
15000 TPS
99 percentile
Read: 6 msRead: 7 msRead: 12 ms
Write: 8 msWrite: 16 msWrite: 20 ms
Kalix Customer“We are confident that Kalix will increase developer productivity and deliver 3X acceleration in the real world.”
Michallis Pashidis,
Founder and CEO, Trust1Team

Managed By Kalix

Runtime Execution of Service

Runtime Execution of Service

Flow of a Service Request

  1. User sends a Request with EntityId as metadata
  2. Entity gets Request, run Business Logic, updates the State and emits an Event representing the State Change
  3. Reply is sent back to the User
  4. After persisting Event in the Event Log it is relayed to the View (read side of CQRS), which is building up a query representation based on the SQL

Flow of a Query

  1. User initiates a Query to the View
  2. The View, managing a live materialized view of the domain data, grabs the ResultSet from DB
  3. Kalix returns a Stream with ResultSets

Service to Service Communication

  1. Service A is communicating with Service B using Brokerless Pub/Sub or RPC over gRPC

External System Communication

  1. Action in Service B is sending Events to an external Message Broker, e.g. Kafka for external system integration

Managed By Kalix

How Kalix implements the Reactive Principles

Stay Responsive

Kalix serves Read Requests at 6 ms and Write Requests at 8 ms latency (at the 99 percentile and moderate load). Kalix ensures this level of responsiveness by leveraging Akka and proven reactive, concurrency, and distributed systems techniques and patterns (see more below).

Accept Uncertainty

Kalix assumes a world with no single “now”. It balances the consistency levels (eventual to strong) always opting for the weakest consistency guarantee that does the job. It offers state models based on logical time, such as CRDTs, and patterns leveraging eventual and causal consistency, such as CQRS and Vector Clocks.

Embrace Failure

Kalix is build on Akka which leverages the Actor Model. Actors are resilient by design and have self-healing capabilities. Failures are expected, planned for, and communicated as values and can as such be dealt with in a structured and safe way. Techniques here include back-pressure, circuit breakers, actor supervision, graceful degradation, bulkheads, failure detection, etc.

Assert Autonomy

Services in Kalix are location transparent and loosely coupled (in time and space) communicating through events transmitted over well-defined protocols. Kalix itself runs on Akka Actors leveraging patterns like state partitioning, consistency boundaries, event sourcing/CQRS, which ensures that the underlying system is built on decoupled, autonomous, location transparent, self-organizing, and self-adapting components.

Tailor Consistency

Every consistency guarantee comes with a cost, which means that always blindly choosing the strongest model can be very wasteful. Kalix’s different state models gives the user a wide range of options—from eventual, to causal, to strong consistency—in choosing the right and most efficient consistency model for its domain data. Techniques include bounded contexts, CRDTs, logical clocks, single writer principle, CQRS, materialized views, etc.

Decouple Time

Communication, I/O, and data processing in Kalix is non-blocking and asynchronous, ensuring efficient management of resources. This also allows for temporal decoupling which increases autonomy and resilience. Techniques employed include async message-passing, event-driven coordination, intermediate queues, brokerless pub/sub, append-only journaling, and streaming.

Decouple Space

We can only create a resilient system if we allow it to live in multiple locations so it can continue function during partial failure. Spatial decoupling allows isolation of failure (so-called bulkheads) avoiding it to cascade throughout the system. Kalix ensures this through data partitioning, bulkheads, async message-passing, actor supervisor hierarchies, location transparent protocols, and more.

Handle Dynamics

Being able to continuously adapt to varying demand and resources is key for any distributed system. Scalability/elasticity does not just mean scaling up; it is equally important to be able to scale down. Kalix embodies this at its core through adaptive auto-scaling at the routing level, service level, and data management and replication level (through Akka Cluster Sharding).

Visit reactiveprinciples.org to learn more.

Managed By Kalix

SRE / Operations

What Kalix takes care of, so you don't have to:

Infrastructure

  • IAM (Identity Access Management)
  • High-Availability Architecture
  • Infrastructure As Code
  • Automation
  • Patching
  • Networking
  • Firewalls
  • Security Groups
  • Load Balancing
  • DNS
  • Kubernetes
  • Service Mesh
  • Node Optimization
  • Ingress

SLAs

  • 99.9% to 99.5% availability SLA
    (depending on plan)

Database

  • Configuration
  • Patching
  • Performance Tuning
  • Disaster Recovery (Backup/Restore)

Observability

  • Basic monitoring
  • Alerting
  • Tracing
  • APM (Application Performance Monitoring)

DevOps/SRE

  • 24/7 Support
  • CI/CD IaC
  • Root Cause Analysis
  • Incident Triage

Security

  • Endpoint Protection
  • Threat Intelligence
  • User/Service Account Lifecycle Management
  • Incident Response

Integrations

  • Kafka
  • AWS SQS/SNS
  • Google Pub/Sub
  • Open Telemetry
  • Grafana
  • Datadog
  • Cloudwatch
  • VPC peering

Compliance

  • SOC2
  • GDPR

Managed By Kalix

Cloud & Edge Deployment

Deploy to AWS/GCP locations. Azure & Edge deployment coming soon.

Auto Generated Reactive Architecture