DEV Community: Jay Ehsaniara

Micro-Containers: Lightweight, Secure Job Execution with Joblet

Jay Ehsaniara — Wed, 02 Jul 2025 20:57:38 +0000

🧱 Micro-Containers: Lightweight, Secure Job Execution with Joblet

In a world increasingly driven by containerization and distributed workloads, developers and platform engineers face a
growing need for fast, secure, and minimal overhead execution environments. Enter the concept of the *
Micro-Container* — a pragmatic middle ground between bare processes and full-featured containers like Docker or
Kubernetes pods.

This article introduces the concept of micro-containers and demonstrates
how Joblet brings this idea to life.

🚀 What Is a Micro-Container?

A micro-container is an execution unit that provides process-level isolation and resource control without the
heavyweight machinery of traditional containers.

Characteristics of a Micro-Container:

Namespace Isolation: Processes are sandboxed using Linux PID, mount, UTS, and network namespaces.
Resource Limits: CPU, memory, I/O, and PID caps enforced via Linux cgroups v2.
Filesystem Segregation: Executed inside a chroot environment or limited mount namespace.
Startup in Milliseconds: No image pull, no daemon — just fork and isolate.
Security-First: TLS/mTLS, user-based access control, no root access required.

This lightweight model is ideal for use cases like:

Ephemeral job runners
Secure execution of user-submitted code
CI/CD pipeline steps
Scripted automation in controlled environments

🛠️ Enter Joblet: A Micro-Container Engine

Joblet is an open-source project that implements the micro-container model
for real-world Linux workloads. It abstracts process isolation and resource management behind a simple CLI and *
gRPC API*, enabling secure, ephemeral job execution with minimal configuration.

Core Features of Joblet:

✅ Linux-native isolation: Uses namespaces, cgroups, and chroot (no Docker/OCI).
✅ gRPC API: Programmatically launch, monitor, and stream jobs.
✅ Real-time logging: Get stdout/stderr via SSE or logs endpoint.
✅ Resource quotas: Limit CPU shares, memory, and block I/O per job.
✅ Security: Enforced TLS + role-based access control (Admin, Viewer).

🧬 Under the Hood

Joblet orchestrates Linux primitives in a tightly integrated flow:

Namespace Isolation: Each job runs in its own PID, mount, and optionally net namespace.
Filesystem Sandboxing: With chroot and custom mount points, jobs are restricted from accessing host files.
cgroups v2 Enforcement: Jobs are assigned to dynamically created cgroups with strict resource boundaries.
Process Lifecycle Management: All subprocesses are cleaned up upon exit or timeout.
Logging & Monitoring: Logs are streamed via Server-Sent Events (SSE), while job metadata (duration, status, resource usage) is tracked internally.

Here’s what launching a secure job might look like:

joblet run --cpu=0.5 --mem=256M --chroot=/sandbox ./my-script.sh

Or via API:

rpc SubmitJob(JobRequest) returns (JobResponse);

🔬 Micro-Containers vs Containers

Feature	Micro-Container (Joblet)	Docker Container
Startup Time	~20–100ms	400–2000ms
Daemon Required	❌	✅
Images Needed	❌ (just binaries/scripts)	✅ (Dockerfile etc.)
Isolation Strength	High (namespace + cgroup)	Very High
Filesystem	Host + chroot	Layered FS
Use Case	CI steps, job runners	Services, microservices

🔐 When to Use Micro-Containers

Joblet’s model shines in situations where:

You don’t want the overhead of Docker or Kubernetes
You need fine-grained CPU/memory control
You execute untrusted or dynamic code
You want fast, low-latency job startup
You’re building multi-tenant pipelines or judges

🌍 Real-World Use Cases

Online Code Judges: Securely run user code submissions in isolated sandboxes.
Internal CI/CD Steps: Replace Docker steps with instant-on, native jobs.
Data Pipelines: Execute preprocessing and validation stages as atomic jobs.
Self-Hosted Serverless Platform: Accept jobs over gRPC and execute them with guarantees.

🧪 Conclusion

The “micro-container” model strikes a powerful balance between raw Linux process execution and full-blown containers. It
gives platform engineers the primitives to isolate, monitor, and control processes without needing Docker, Kubernetes,
or VMs.

Joblet brings this model to life with a clean, efficient, and secure implementation — a single binary that gives you
safe multi-tenant job execution out of the box.

Ready to try it?
👉 GitHub – Joblet

Let me know if you'd like this converted into a Markdown article for GitHub Pages or Dev.to, or if you'd like a logo or
diagram to accompany it.

gRPC between Web and Server.

Jay Ehsaniara — Fri, 30 Aug 2024 14:32:10 +0000

This project demonstrates how to set up a simple gRPC communication between a web client and server with an Envoy proxy.

I’m using the gRPC-Web library for this purpose. gRPC-Web is a JavaScript client library that allows web applications to interact with gRPC services. Since browsers don't support HTTP/2 or the binary protocol used by standard gRPC, gRPC-Web provides a way to bridge the gap by using HTTP/1.1 or HTTP/2 and encoding gRPC messages in a way that browsers can handle. Here's how gRPC-Web works:

The client sends requests to the server using gRPC-Web, which typically communicates via HTTP/1.1 or HTTP/2. Metadata (like headers) can be attached to the request, such as for authentication (e.g., JWT tokens).

The request is encoded in a gRPC-Web format, typically using base64 encoding for the binary gRPC payload. The client sends this request over HTTP/1.1 or HTTP/2.

Envoy (or another reverse proxy like Nginx) acts as an intermediary between the gRPC-Web client and the gRPC server. Envoy receives the gRPC-Web request, decodes the gRPC-Web payload, and forwards it as a standard gRPC request to the gRPC server using HTTP/2.

The gRPC server processes the request as if it were a native gRPC request, using HTTP/2 for communication.

The gRPC server processes the incoming gRPC request, performs the necessary business logic, and generates a response (in this example it’s the Go written application). The response is encoded in the standard gRPC format and sent back to Envoy.
Envoy receives the gRPC response, encodes it in the gRPC-Web format (typically using base64), and sends it back to the gRPC-Web client over HTTP/1.1 or HTTP/2. Any metadata included in the gRPC response, such as status codes, is translated appropriately.
The gRPC-Web client decodes the response and converts it into a usable format within the web application. The web application processes the response, updating the UI or handling errors as needed.

NOTE: client-side and bi-directional streaming is not currently supported (see streaming roadmap)

Advantages of gRPC-Web

Browser Compatibility: Allows modern web applications to interact with gRPC services without needing native support for HTTP/2 and binary protocols.
Efficiency: Leverages the performance and efficiency of gRPC while adapting it for the web.

Here is a GitHub project for it:

https://github.com/ehsaniara/gRPC-web-example

proto file

syntax = "proto3";

package helloworld;

option go_package = "./proto"; // Add this line

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

server side (go)

package main

import (
   "context"
   "google.golang.org/grpc/reflection"
   "log"
   "net"

   pb "github.com/ehsaniara/gRPC-web-example/proto"
   "google.golang.org/grpc"
)

type server struct {
 pb.UnimplementedGreeterServer
}

func (s *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {
 return &pb.HelloReply{Message: "Hello " + in.Name}, nil
}

func main() {
 lis, err := net.Listen("tcp", ":50051")
 if err != nil {
  log.Fatalf("failed to listen: %v", err)
 }
 s := grpc.NewServer()
 pb.RegisterGreeterServer(s, &server{})

 // Register reflection service on gRPC server.
 reflection.Register(s)
 if err := s.Serve(lis); err != nil {
  log.Fatalf("failed to serve: %v", err)
 }

 log.Println("Server is running on port 50051")
 if err := s.Serve(lis); err != nil {
  log.Fatalf("failed to serve: %v", err)
 }
}

Envoy config

...
http_filters:
  - name: envoy.filters.http.grpc_web
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_web.v3.GrpcWeb
  - name: envoy.filters.http.cors
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.cors.v3.Cors
  - name: envoy.filters.http.router
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
...

JS Web Client (webpack)

// Import the generated gRPC-Web client stubs and message classes
import {GreeterClient} from './generated/helloworld_grpc_web_pb';
import {HelloRequest} from './generated/helloworld_pb';

// Create an instance of the Greeter client
const client = new GreeterClient('http://localhost:8080');

// Function to send a greeting request
function sayHello(name) {
    // Create a new request
    const request = new HelloRequest();
    request.setName(name);

    // Call the sayHello method on the Greeter client
    client.sayHello(request, {}, (err, response) => {
        if (err) {
            console.error('Error:', err.message);
            document.getElementById('output').textContent = 'Error: ' + err.message;
        } else {
            console.log('Greeting:', response.getMessage());
            document.getElementById('output').textContent = 'Greeting: ' + response.getMessage();
        }
    });
}

// Example usage: sending a request when the page loads
document.addEventListener('DOMContentLoaded', () => {
    const name = 'World';
    sayHello(name);
});

Here is a GitHub project related to this project

https://github.com/ehsaniara/gRPC-web-example

Go Interval job timer, with centralized Lock for Distributed Systems

Jay Ehsaniara — Sun, 01 Aug 2021 02:32:40 +0000

goInterLock

known as: ⏰ Interval (Cron / Job / Task / Scheduler) ⏱️

GoInterval job timer, with centralize Lock

goInterLock is schedule tasks (cron-job) with a centralized locking mechanism for Go (AKA Golang). In the distributed systems, the lock prevents the tasks to been executed in every instant that has the scheduler.

For example, if your application has a scheduled where it's calling some external API or doing some expensive DataBase querying every 10 minutes, the lock prevents the process to be run in every instance of that application, and you ended up running that task multiple times every 10 minutes.

Ideal use cases:

Kubernetes
Docker Swarm
AWS ECS Fargate Quick Start

go get github.com/ehsaniara/gointerlock

Supported Lock

Redis
AWS DynamoDB
Postgres DB (coming soon)

Local Scheduler (Single App)

(Interval every 2 seconds)

var job = gointerlock.GoInterval{
    Interval: 2 * time.Second,
    Arg:      myJob,
}
err := job.Run(ctx)
if err != nil {
        log.Fatalf("Error: %s", err)
}

Examples

Basic Local Task: Simple Task Interval (Single App).

Application Cache: An example of periodically cached value update on http server.

Distributed Mode (Scaled Up)

Redis

Existing Redis Connection

you should already configure your Redis connection and pass it into the GoInterLock. Also make sure you are giving the
unique name per job

Step 1: configure redis connection redisConnection.Rdb from the existing application and pass it into the Job. for example:

var redisConnector = redis.NewClient(&redis.Options{
    Addr:     "localhost:6379",
    Password: "myRedisPassword", 
    DB:       0,               
})

Step 2: Pass the redis connection into the GoInterval

var job = gointerlock.GoInterval{
    Interval: 2 * time.Second,
    Arg:      myJob,
    Name:     "MyTestJob",
    RedisConnector: redisConnector,
}
err := jobTicker.Run(ctx)
if err != nil {
    log.Fatalf("Error: %s", err)
}

in both examples myJob is your function, for example:

func myJob() {
    fmt.Println(time.Now(), " - called")
}

Note: currently GoInterLock does not support any argument for the job function

Built in Redis Connector

another way is to use an existing redis connection:

var job = gointerlock.GoInterval{
    Name:          "MyTestJob",
    Interval:      2 * time.Second,
    Arg:           myJob,
    RedisHost:     "localhost:6379",
    RedisPassword: "myRedisPassword", //if no pass leave it as ""
}
err := job.Run(context.Background())
if err != nil {
    log.Fatalf("Error: %s", err)
}

GoInterLock is using go-redis for Redis Connection.

Examples

Basic Distributed Task: Simple Task Interval with Redis Lock.

AWS DynamoDb

Basic Config (Local Environment)

This ia sample of local DynamoDb (Docker) for your local test.

var job = gointerlock.GoInterval{
    Name:                       "MyTestJob",
    Interval:                   2 * time.Second,
    Arg:                        myJob,
    LockVendor:                 gointerlock.AwsDynamoDbLock,
    AwsDynamoDbRegion:          "us-east-1",
    AwsDynamoDbEndpoint:        "http://127.0.0.1:8000",
    AwsDynamoDbSecretAccessKey: "dummy",
    AwsDynamoDbAccessKeyID:     "dummy",
}
err := job.Run(cnx)
if err != nil {
    log.Fatalf("Error: %s", err)
}

task:

func myJob() {
    fmt.Println(time.Now(), " - called")
}

Note: you can get the docker-compose file from AWS DynamoDB Docker compose or you can get it from: docker-compose.yml.

Using AWS Profile

goInterLock will get credentials from the AWS profile

var job = gointerlock.GoInterval{
    Name:                       "MyTestJob",
    Interval:                   2 * time.Second,
    Arg:                        myJob,
    LockVendor:                 gointerlock.AwsDynamoDbLock,
}
err := job.Run(cnx)
if err != nil {
    log.Fatalf("Error: %s", err)
}

Examples

Basic Distributed Task: Simple Task Interval with DynamoDb Lock.

🍀 Just the centralized lock for distributed system (No Timer/Scheduler)


import (
    "context"
    "fmt"
    "time"

    "github.com/go-redis/redis/v8"
)

type DistributedLock interface {
    Lock(ctx context.Context, lockName string, maxLockingDuration time.Duration) bool
    UnLock(ctx context.Context, lockName string)
}

func NewDistributedLock(rdb *redis.Client) DistributedLock {
    return &distributedLock{
        rdb: rdb,
    }
}

type distributedLock struct {
    rdb *redis.Client
}

// Lock return TRUE when successfully locked, return FALSE if it's already been locked by others
func (d distributedLock) Lock(ctx context.Context, lockName string, maxLockingDuration time.Duration) bool {
    key := fmt.Sprintf("lock_%s", lockName)
    //check if it's already locked
    iter := d.rdb.Scan(ctx, 0, key, 0).Iterator()
    for iter.Next(ctx) {
        //exit if lock exist
        return false
    }
    //then lock it then
    d.rdb.Set(ctx, key, []byte("true"), maxLockingDuration)
    return true
}

func (d distributedLock) UnLock(ctx context.Context, lockName string) {
    key := fmt.Sprintf("lock_%s", lockName)
    //remove the lock
    d.rdb.Del(ctx, key)
}

ElasticSearch Parallel Pagination by Kafka

Jay Ehsaniara — Sat, 09 Jan 2021 20:09:38 +0000

By Using Kafka we can easily horizontally scale our application to do asynchronous pagination in ElasticSearch.

Let’s say you have an ElasticSearch Index of 1,000,000 documents, and you need to run an operation on those documents. We already know how expensive the deep-paging in ElasticSearch is, especially index.max_result_window and doing Search ‘from:’.

GET /_search
{
  "from": 5,
  "size": 20,
  "query": {
    "match": {
      "user.id": "jay"
    }
  }
}

One way of overcoming the problem is to use search_after. In this case, your process is becoming synchronous, which means you cannot call the second chunk of data without having the results from the first call, for example:

GET /_search
{
  "size": 10000,
  "query": {
    "match" : {
      "user.id" : "jay"
    }
  },
  "sort": [ 
    {"@timestamp": "asc"}
  ]
}

results:

{
  "took" : ...,
  "timed_out" : false,
  "_shards" : ...,
  "hits" : {
    "total" : ...,
    "max_score" : null,
    "hits" : [
      ...
      {
        "_source" : ...,
        "sort" : [                                
          4098435132000
        ]
      }
    ]
  }
}

As you can see, the results give you a sort value (4098435132000) where you can use in your second call-in “search_after” to get the next chunk as:

GET /_search
{
  "size": 10000,
  "query": {
    "match" : {
      "user.id" : "jay"
    }
  },
  "sort": [
    {"@timestamp": "asc"}
  ],
  "search_after": [                                
    4098435132000
  ]
}

then get the next sort value and use it in your next call.

This process is sequentially asynchronous, which means to get through 1,000,000 documents you need to call ES 1,000,000/10,000=100 times one after the other.

What can go wrong?

let’s say your application dies or runs out of memory during these calls
how to know where to start after it failed
maybe this process is very slow for your application use-case

Solution By Using “Slice”

One call to ES to get the count of the documents (which in this case is 1M), then create a Kafka producer to put the sequences (0–100) into your Kafka topic and define your partition size as the number of your consumer app. Let’s say you have 10 consumer applications.

Create a Kafka consumer app, which is calling Elastic Search as:

GET /_search?scroll=1m
{
  "slice": {
     "id":0,
     "max":100  
  },
  "size": 10000,
  "sort": [
    {"@timestamp": "asc"}
  ]
}

The consumer gets the sequence number as a parameter and replaces it with the id. As long as all consumers have the same consumer “group.id” they can process these calls in parallel and have a resilient framework.

Implementation with Java/Spring Cloud

I happened to use java with spring cloud for my project.

Let’s run your Elastic Search and Kafka in docker-compose by running the following command:

# Elastic Search
docker-compose -f docker-compose-es.yml up -d
# Kafka
docker-compose -f docker-compose-kafka.yml up -d

you can find the docker-compose-es.yml and docker-compose-kafka.yml in my Github account.

The producer first calls ES to get the count of the documents in the index, then divides the count by 500, which will be the number of documents you expect to be retrieved in every ES call.

public void paginationProcess() {
    log.debug("paginationProcess called");
    //call to ES and get the total count
    Response response = restHighLevelClient.getLowLevelClient()
    .performRequest(new Request("GET", String.format("%s/_count", INDEX_NAME)));

    ResponseCountDto responseCountDto = objectMapper.readValue(EntityUtils.toString(response.getEntity()), ResponseCountDto.class);

    log.debug("responseCountDto: {}", responseCountDto.getCount());

    //let say you want to have a page size of 500 then count / 500

    int max = responseCountDto.getCount() / 500;
    log.debug("count: {} , max: {}", responseCountDto.getCount(), max);

    //producer
    IntStream.range(0, max).forEach(i -> paginationBinder.paginationOut()//
    .send(MessageBuilder.withPayload(//
    PaginationDto.builder()//
    .id(i)//slice id
    .max(max)// let say i want to have page size of 500 then: count / 500
    .build())//
    .setHeader(MessageHeaders.CONTENT_TYPE, MimeTypeUtils.APPLICATION_JSON).build()));
}

Then the Consumer receives the slice number as a parameter. In case of any error in the consumer method, we retry it 5 times, and then it puts the message into to DLQ method.

 @StreamListener(PaginationBinder.PAGINATION_IN)
    public void paginationProcess(@Payload PaginationDto paginationDto) {
        // Call ES
        log.debug("paginationProcess: {}", paginationDto);
        try {
            Request request = new Request("GET", String.format("%s/_search?scroll=1m", INDEX_NAME));
            //sorted by localDateTime and slice by id and max as parameters
            request.setJsonEntity(String.format("{\"slice\":{\"id\":%s,\"max\":%s},\"size\":10000,\"sort\":[{\"localDateTime\":\"asc\"}]}", paginationDto.getId(), paginationDto.getMax()));
            Response response = restHighLevelClient.getLowLevelClient().performRequest(request);
            //do something with the response ...
            log.debug("response: {}", response);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

Note: Assume no new documents are inserting into the result set or at least within that period. Otherwise, we lose the consistency of the result during the pagination.

application.yml file

spring:
  application:
    name: es-pagination

  cloud.stream:
    bindings:

      pagination-out:
        destination: pagination
        producer:
          partition-count: 10
      pagination-in:
        destination: pagination
        group: ${spring.application.name}.pagination-group
        consumer:
          maxAttempts: 5
      pagination-in-dlq:
        destination: paginationDLQ
        group: ${spring.application.name}.pagination-group

    kafka:
      streams:
        bindings:
          pagination-in:
            consumer:
              enableDlq: true
              dlqName: paginationDLQ
              autoCommitOnError: true
              autoCommitOffset: true
        binder:
          autoAddPartitions: true
          min-partition-count: 10
          configuration:
            commit.interval.ms: 100
            default.key.serde: org.apache.kafka.common.serialization.Serdes$StringSerde
            default.value.serde: org.apache.kafka.common.serialization.Serdes$StringSerde

Avoid toasting the memory

If the number of slices is bigger than the number of shards, the slice filter will become very slow on the first calls. It has a complexity of O(N) and a memory cost which equals N bits per slice where N is the total number of documents in the shard. After a few calls, the filter should be cached and subsequent calls should be faster, but you should limit the number of sliced queries you perform in parallel to avoid the memory explosion.

You can find the project in my Github account:
https://github.com/ehsaniara/es-kafka-pagination

Refrence:
https://www.elastic.co/guide/en/elasticsearch/reference/current/paginate-search-results.html

Spring Boot 2 with Multiple DataSources

Jay Ehsaniara — Wed, 19 Feb 2020 08:18:05 +0000

Spring Boot 2 with Multiple DataSource

There are times that even having the best DataBase (PostgresSql, Oracle, MySql, .. ) Tuning can not be as help-full as Application Level separating Read and Writes

Spring Boot 2.2.2 with Multiple DataSource

Postgres Setup

For This Demo you need 2 separate Postgres DataBase where one as Master and the other re one as a replica.

for simplicity just run:

docker-compose up --force-recreate

The docker-compose.yml is already in the project which contains 2 PostgresSql in 2 different ports, with demo DataBase

Note: you can always uninstall it as: docker-compose down if you needed to.

you can clone this project from my github on https://github.com/ehsaniara/spring-boot-multi-data-source

Spring Boot Setup

From https://start.spring.io/ select web, data-jpa, lombok, postgresDriver

Once you Generate and download the zip file, you should have similar POM file as:


<dependencies>

   <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
   </dependency>

   <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-jpa</artifactId>
   </dependency>

   <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-configuration-processor</artifactId>
   </dependency>

   <dependency>
      <groupId>org.projectlombok</groupId>
      <artifactId>lombok</artifactId>
      <optional>true</optional>
   </dependency>

   <dependency>
      <groupId>org.postgresql</groupId>
      <artifactId>postgresql</artifactId>
      <scope>runtime</scope>
   </dependency>


</dependencies>

for this demo I use HikariDataSource as a default connection pool library by Spring Boot 2.2.2
we need to have 2 separate DataSource and EntityManager one for the Writes(Master/Primary) and one for Reads(Slave/Secondary).


spring:
  datasource-write:
    driver-class-name: org.postgresql.Driver
    jdbc-url: jdbc:postgresql://localhost:5432/demo
    username: 'postgres_user_for_db_write'
    password: 'you_password'
    platform: postgresql
    hikari:
      idle-timeout: 10000
      maximum-pool-size: 10
      minimum-idle: 5
      pool-name: WriteHikariPool

  datasource-read:
    driver-class-name: org.postgresql.Driver
    jdbc-url: jdbc:postgresql://localhost:5433/demo
    username: 'postgres_user_for_db_read'
    password: 'you_password'
    platform: postgresql
    hikari:
      idle-timeout: 10000
      maximum-pool-size: 10
      minimum-idle: 5
      pool-name: ReadHikariPool

as you see I have 2 data-source as: datasource-write and datasource-read with their own credentials.

DataSource Configurations for WriteDB:

@Configuration
@ConfigurationProperties("spring.datasource-write")
@EnableTransactionManagement
@EnableJpaRepositories(
        entityManagerFactoryRef = "entityManagerFactoryWrite",
        transactionManagerRef = "transactionManagerWrite",
        basePackages = {"com.ehsaniara.multidatasource.repository.writeRepository"}
)
public class DataSourceConfigWrite extends HikariConfig {

    public final static String PERSISTENCE_UNIT_NAME = "write";

    @Bean
    public HikariDataSource dataSourceWrite() {
        return new HikariDataSource(this);
    }

    @Bean
    public LocalContainerEntityManagerFactoryBean entityManagerFactoryWrite(
            final HikariDataSource dataSourceWrite) {

        return new LocalContainerEntityManagerFactoryBean() {{
            setDataSource(dataSourceWrite);
            setPersistenceProviderClass(HibernatePersistenceProvider.class);
            setPersistenceUnitName(PERSISTENCE_UNIT_NAME);
            setPackagesToScan(MODEL_PACKAGE);
            setJpaProperties(JPA_PROPERTIES);
        }};
    }

    @Bean
    public PlatformTransactionManager transactionManagerWrite(EntityManagerFactory entityManagerFactoryWrite) {
        return new JpaTransactionManager(entityManagerFactoryWrite);
    }
}

DataSource Configurations for ReadDB:

@Configuration
@ConfigurationProperties("spring.datasource-read")
@EnableTransactionManagement
@EnableJpaRepositories(
        entityManagerFactoryRef = "entityManagerFactoryRead",
        transactionManagerRef = "transactionManagerRead",
        basePackages = {"com.ehsaniara.multidatasource.repository.readRepository"}
)
public class DataSourceConfigRead extends HikariConfig {

    public final static String PERSISTENCE_UNIT_NAME = "read";


    @Bean
    public HikariDataSource dataSourceRead() {
        return new HikariDataSource(this);
    }

    @Bean
    public LocalContainerEntityManagerFactoryBean entityManagerFactoryRead(
            final HikariDataSource dataSourceRead) {

        return new LocalContainerEntityManagerFactoryBean() {{
            setDataSource(dataSourceRead);
            setPersistenceProviderClass(HibernatePersistenceProvider.class);
            setPersistenceUnitName(PERSISTENCE_UNIT_NAME);
            setPackagesToScan(MODEL_PACKAGE);
            setJpaProperties(JPA_PROPERTIES);
        }};
    }

    @Bean
    public PlatformTransactionManager transactionManagerRead(EntityManagerFactory entityManagerFactoryRead) {
        return new JpaTransactionManager(entityManagerFactoryRead);
    }
}

Read and Write repositories should be in a separated packages :

Write: com.ehsaniara.multidatasource.repository.writeRepository

Read: com.ehsaniara.multidatasource.repository.readRepository

you also need to set:

public final static String MODEL_PACKAGE = "com.ehsaniara.multidatasource.model";

public final static Properties JPA_PROPERTIES = new Properties() {{
    put("hibernate.dialect", "org.hibernate.dialect.PostgreSQL10Dialect");
    put("hibernate.hbm2ddl.auto", "update");
    put("hibernate.ddl-auto", "update");
    put("show-sql", "true");
}};

and the actual logic are in the service layer:

@Service
public class CustomerServiceImpl implements CustomerService {

    private final CustomerReadRepository customerReadRepository;
    private final CustomerWriteRepository customerWriteRepository;

    public CustomerServiceImpl(CustomerReadRepository customerReadRepository, CustomerWriteRepository customerWriteRepository) {
        this.customerReadRepository = customerReadRepository;
        this.customerWriteRepository = customerWriteRepository;
    }

    public Optional<Customer> getCustomer(Long id) {
        return customerReadRepository.findById(id);
    }

    public Customer createCustomer(Customer customer) {

        Assert.notNull(customer, "Invalid customer");
        Assert.isNull(customer.getId(), "customer id should be null");
        Assert.notNull(customer.getName(), "Invalid customer name");

        return customerWriteRepository.save(customer);
    }

    public Customer updateCustomer(Customer customer) {

        Assert.notNull(customer, "Invalid customer");
        Assert.notNull(customer.getId(), "Invalid customer id");

        return customerWriteRepository.save(customer);
    }
}

Now if run this line you create customer in DB1:

curl -H "Content-Type: application/json" --request POST --data '{"name":"Jay"}'   http://localhost:8080/customer

curl -H "Content-Type: application/json" --request PUT --data '{"id":1 , "name":"Jay ehsaniara"}'   http://localhost:8080/customer

But if you run this line you getting data from DB2:

 curl --request GET  http://localhost:8080/customer/1

Note: you need to insert customer manually in DB2 since it has no pre customer. and we haven't setup Postgres Replication yet