DEV Community: Akshay Kumar

From One Server to Millions: How Scaling Works in System Design

Akshay Kumar — Thu, 06 Nov 2025 13:14:09 +0000

What is Scalability?

Number of requests a system can handle simultaneously. For this we can either add more resources to infrastructure or make our current infrastruction advanced.

Scaling is basically increasing the capability of our system to handle large number of requests.

How to scale our system?

Well, there are two ways a system can be scaled —

Vertical scaling
Horizontal scaling

Vertical Scaling —

In vertical scaling, we make our infrastructure bulky hence making it more capable to handle more requests. This can be done by introducing more CPU, GPU, RAM, Disks etc.

Vertical scaling must be the first step to scale a system, because it is less expensive than horizontal scaling and its better to utilise the maximum capacity of current infrastructure.

Vertical scaling is also called Scaling Up.

Horizontal Scaling —

In Horizontal scaling or Scaling out , we add more machines to the current infrastructure. This can be done by adding more servers, databases, load balancers, etc to handle more requests.
Adding a whole new machine is expensive compared to increasing the machine’s capability(Vertical Scaling). So the best way to scale a system is first scaling it vertically and then going to horizontal scaling further.

In case of horizontal scaling, we need a load balancer to forward the requests to other machines.

With horizontal scaling we can enable our application to scale infinitely.

Lets take a scenario where we need to scale our database.

Scaling our Database —

Firstly, we vertically scale our database and make it

Press enter or click to view image in full size

now, we can create read replicas to handle read requests from users.

The primary database here can also be called a master db. Its job is to write the updates to the read replicas.
So the read requests can be served by the read replicas, and write requests by the master node. Hence, not overwhelming the master node with read requests.

If our application is read intensive then this design is fine, if it is write intensive as well, we can create a replica for write db too.

Strategy Design Pattern in Java

Akshay Kumar — Sat, 11 Oct 2025 09:49:56 +0000

Strategy is a behavioral design pattern that turns a set of behaviors into objects and makes them interchangeable inside original context object.

Lets take an example of payment methods —
Suppose we have to create an application, where a user can pay using either a card or UPI.

A general code for doing above can be written like below —

if (paymentMethod.equals("1")) {
    PayPal p = new PayPal();
    p.pay(amount);
} else if (paymentMethod.equals("2")) {
    CreditCard c = new CreditCard();
    c.pay(amount);
} else if (paymentMethod.equals("3")) {
    GooglePay g = new GooglePay();
    g.pay(amount);
}

Here, we have created 3 classes for each payment type. And the above code is being called from a resource layer or business layer.

Now, if we recall the SOLID principles, we can easily see the violation of Open/Closed principle. Because later if more methods are added, we’ll need to change the code in client class. But if we do following

if (paymentMethod.equals("1")) {
    PaymentStrategy p = new PayPal();
    p.pay(amount);
} else if (paymentMethod.equals("2")) {
    PaymentStrategy c = new CreditCard();
    c.pay(amount);
} else if (paymentMethod.equals("3")) {
    PaymentStrategy g = new GooglePay();
    g.pay(amount);
}

where PaymentStrategy is an interface and all the strategy classes extend this. Does this solve the problem. Well, not entirely. Because we still have Open/Closed principle being violated due to addition of a new if else clause and imports for that strategy too.
So what would be the right way to do it?

Lets find out.

public class PaymentStrategyFactory {
    private static final Map<String, PayStrategy> strategies = Map.of(
        "paypal", new PayByPayPal(),
        "creditcard", new PayByCreditCard(),
        "googlepay", new PayByGooglePay()
    );

    public static PayStrategy getStrategy(String method) {
        return strategies.get(method.toLowerCase());
    }
}

Here, we have a factory entirely designed to take care of the strategies.
The map is of types String, PayStrategy. And all the strategies implements this interface. So we dont need to define the specific strategy class. Factory would take care of all of them.

getStrategy() method is used to fetch the instance of the strategy that is called from the client code. So client code would look like following —

PayStrategy strategy = PaymentStrategyFactory.getStrategy(paymentMethod);
strategy.pay();

here paymentMethod could contain “paypal” or “creditCard” or “googlePay”.
So we don’t need to change anything in client code.

Why 2-Phase Commit Fails in Microservices — And How the Saga Pattern Saves the Day

Akshay Kumar — Thu, 31 Jul 2025 13:10:13 +0000

When talking about microservices, it consists of multiple services communicating with each other giving the application an edge over the monolytic architecture.

But the biggest problem encountered in a micro-service architecture is how to handle the transaction that spans multiple services.
Hence making data consistency across the service database a big challenge. In a micro-service architecture, every service can have its own database, tech stack and database.

So when a transaction has to depend on more than one service, data consistency is needed.

Distributed transactions —

In the above diagram, we have 4 services with their transactions. To ensure a successful order processing service, all four microservices must complete their indivicual transactions. If any transaction fails, all the preceding transaction updates must be rolled back.

But the distrubuted transactions have following challenges —

It must maintain ACID : To ensure correctness of a transaction, it must be atomic, consistent, isolated and durable. As in this scenario, the transaction spans multiple services, ensuring ACID is a big challenge.
Isolation of transactions : If a common object is changed by one service and is read by another service, there is data inconsistency.

To overcome these limitations, 2 Phase-Commit can be used.

Two Phase Commit —

The Two-Phase Commit protocol (2PC) is a widely used pattern to implement distributed transactions. We can use this pattern in a microservice architecture to implement distributed transactions.

In two phase commit, there is a central body called coordinator which is connected to the services which is responsible to control the transactions and contains the logic to manage the transactions.

The two phase commit runs a distributed transaction in two phases —
Phase 1 **: In this phase, coordinator asks all the nodes whether they are ready to commit the transaction or not.
**Phase 2 : In this phase, depending on the ack received by the nodes, if all ack are yes, then the coordinator asks all of them to commit. Otherwise, if even one ack is a no, then the coordinator tells all the nodes to roll back their transactions.

2 PC sounds great. But what is the problem with this design?

Single Point of Failure(SPoF) — If the coordinator is down, the whole system goes down.
All the services need to wait for the slowest service for confirmation. So, the overall performance of the transaction is bound by the slowest service. 3. Two-phase commit protocol is not supported in NoSQL databases.

SAGA Architecture Pattern The SAGA pattern provides transaction management using a sequence of local transactions. Each service is considered as a SAGA participant and each participant has its individual transaction. SAGA makes sure that either all the transactions complete successfully or the corresponding compensation transactions are run to undo the work previously completed ie. bascially rolling back the other transactions.
In this pattern, the compensation transactions must me idempotent and retryable.

The Saga Execution Coordinator (SEC) guarantees these principles:

The Saga Execution Coordinator is a central component used to implement a SAGA flow. It contains a saga log that captures the sequence of events of a distributed transaction.
In the diagram below, the success scenario is shown for all the transactions completed and the logs captured in the saga log.

There are two approaches to implement SAGA design pattern —

SAGA Choreography Pattern
SAGA Orchestration Pattern

SAGA Chorography Pattern

In this pattern, each microservice pushes an event to be fetched by the next microservice. Here the microservices should have their individual transactions and be a part of the Saga.
In this pattern, the Saga Execution Coordinator is either embedded within the microservice or can be a standalone component. In the Saga, choreography flow is successful if all the microservices complete their local transaction, and none of the microservices reported any failure.
So, if two services ran successfully and the third failed, the other services listen to the event of failure and roll back their own transactions. Hence eliminating the SPOF.

The following diagram demonstrates the successful Saga flow for the online order processing application:

In the case of failure, the microservice logs the failure in the log and reports the failure to SEC and its SEC’s responsibility to run the compensating transactions using the logs and keep retrying of it fails.

In this example, the Payment microservice reports a failure, and the SEC invokes the compensating transaction to unblock the seat. If the call to the compensating transaction fails, it is the SEC’s responsibility to retry it until it is successfully completed.
Recall that in Saga, a compensating transaction must be idempotent and retryable. The Choreography pattern works for greenfield (from scratch) microservice application development. Also, this pattern is suitable when there are fewer participants in the transaction.
Here are a few frameworks available to implement the choreography pattern:

Axon Saga — a lightweight framework and widely used with Spring Boot-based microservices
Eclipse MicroProfile LRA — implementation of distributed transactions in Saga for HTTP transport based on REST principles
Eventuate Tram Saga — Saga orchestration framework for Spring Boot and Micronaut-based microservices.

SAGA Orchestration Pattern

In this pattern, a single orchestrator is responsible for managing the overall transaction status. If any of the microservices encounter a failure, the orchestrator is responsible for invoking the necessary compensating transactions:

The Saga orchestration pattern is useful for brownfield microservice application development architecture. In other words, this pattern works when we already have a set of microservices and would like to implement the Saga pattern in the application.
We need to define the appropriate compensating transactions to proceed with this pattern. It is different from choreography, as the orchesrator decides every thing and has the control with it. Whereas in choreography, one service has to send event to next, which makes the services in control.

Here are a few frameworks available to implement the orchestrator pattern:

Camunda is a Java-based framework that supports Business Process Model and Notation (BPMN) standard for workflow and process automation.
Apache Camel provides the implementation for Saga Enterprise Integration Pattern (EIP).

Conclusion

In this article, we discussed the Saga architecture pattern to implement distributed transactions in a microservice-based application.
We first introduced the challenges of these implementations.
We then explored the two-phase commit protocol, a popular alternative of Saga, and examined its limitation to implement distributed transactions in microservice-based applications.
Lastly, we discussed the Saga architecture pattern, how it works and the two main approaches to implementing the Saga pattern in microservice-based applications.

Spring Security Part 2 : Getting started with jdbc authentication

Akshay Kumar — Sat, 12 Apr 2025 07:54:24 +0000

Kudos 👏 to reach till here.
In the previous article, we were implementing in-memory authentication in Spring security. But what if we need to connect to a datasource instead of an in-memory.
In this article, we’ll fo throught JDBC authentication.

Most of the concept is same as before, the only difference is setting up a jdbc authentication in the configure method.

Below is the code —

@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
  @Override 
  protected void configure (AuthenticationManagerBuilder auth) {
    auth.jdbcAuthentication();
  }
  @Override
  protected void configure (HttpSecurity http) {
    http.authorizeRequests()
        .antMatchers("/admin").hasRole("ADMIN").
        .antMatchers("/user").hasAnyRole("ADMIN","USER").
        .antMatchers("/**").permitAll().
        .hasAnyRole();
  }
}

Now, we need to setup our authentication to tell Spring Security to lookup the user and password in the database. To do so, we need a bean for data source. By default, Spring security provides DataSource class which we can autowire in our project.

@Autowired
DataSource datasource;
@Override 
  protected void configure (AuthenticationManagerBuilder auth) {
    auth.jdbcAuthentication()
        .dataSource(dataSource);
  }

But how does the spring knows the configuration of the data source.
We must configure it somewhere or else if we’re using H2 which is in-memory database, then spring by default creates a datasource.

For now, lets assume we have H2 in our class path.

@Autowired
DataSource datasource;
@Override 
  protected void configure (AuthenticationManagerBuilder auth) {
    auth.jdbcAuthentication()
        .dataSource(dataSource);
        .dataSource(dataSource)
        .withDefaultSchema()
        .withUser(
        user.withUserName("user")
            .password("pass")
            .roles("USER")
            .withUserName("admin")
            .password("pass")
            .roles("ADMIN")
        );
  }

In the above code, we’re using a default schema and creating the users.
When a client sends a request along with a password, the authentication configuration creates these 2 users and checks do the user in request matches to these. Hence authenticating the request.

Now, what if we already have a schema or we don’t want to use the default schema and you don’t want to put user creation logic in the code?
Create your own schema in resources -> schema.sql

schema.sql :

create table users(
 username varchar_ignorecase(50) not null primary key,
 password varchar_ignorecase(50) not null,
 enabled boolean not null
);

create table authorities (
 username varchar_ignorecase(50) not null,
 authority varchar_ignorecase(50) not null,
 constraint fk_authorities_users foreign key(username) references users(username)
);
create unique index ix_auth_username on authorities (username,authority);

data.sql :

INSERT INTO users (username, password, enabled) VALUES 
('user', 'pass', true),
('admin', 'pass', true);

INSERT INTO authorities (username, authority) VALUES 
('user', 'ROLE_USER'),
('admin', 'ROLE_ADMIN');
Important notes:

The password should ideally be encoded (BCrypt is recommended) rather than stored in plain text like this
Spring Security expects the authorities/roles to be prefixed with “ROLE_” by default
The enabled column must be set to true for the users to be able to authenticate
Below is the complete code for configuration class:

@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
  @Autowired
  DataSource dataSource;

  @Override 
  protected void configure(AuthenticationManagerBuilder auth) throws Exception {
    auth.jdbcAuthentication()
        .dataSource(dataSource)
        .passwordEncoder(passwordEncoder());
  }

  @Override
    protected void configure (HttpSecurity http) {
      http.authorizeRequests()
        .antMatchers("/admin").hasRole("ADMIN").
        .antMatchers("/user").hasAnyRole("ADMIN","USER").
        .antMatchers("/**").permitAll().
        .hasAnyRole();
  }

  @Bean
  public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
  }
}

When you autowire DataSource and use it in auth.jdbcAuthentication(), Spring Security automatically uses this DataSource to query the database for user authentication.

By default, it looks for tables: users (with username, password, enabled columns) , authorities (with username, authority columns)

If your schema is different, you can customize the queries.

auth.jdbcAuthentication()
        .dataSource(dataSource)
        .usersByUsernameQuery("Select username, password, enables"
        + "from custom_users where username = ?")
        .authoritiesByUsernameQuery("Select username, authority "
        + "from authorities where username = ?");

If you’re using MySQL, you need to define the DataSource in application.properties:

spring.datasource.url=jdbc:mysql://localhost:3306/spring_security_db
spring.datasource.username=root
spring.datasource.password=password
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

Great 👏

You’ve now got a good idea about spring security and jdbc authentication.

Next, let’s dive deep into JWT and implementing it using Spring security.
Thanks for reading.

Secure Your APIs and Web Apps using Spring Security

Akshay Kumar — Wed, 09 Apr 2025 14:19:20 +0000

Security. Yeah, we know, it can feel like a chore. Especially when you’re just trying to build something awesome. But trust me, skipping security is like leaving your front door wide open. That’s where Spring Security comes in — it’s your trusty sidekick for locking things down in your Spring apps. Think of it as the bouncer for your code, making sure only the right people get in.

Before diving into the main part, first lets understand the difference between two widely used and similar meaning(not exaclty) words —

Authentication and Authorization

They both are related to security. Well thats true. But how does both differ from one another.
Simply put, Authentication means WHO ARE YOU?
and Authorization means WHAT DO YOU WANT TO ACCESS?

Not same right?

When we talk about authentication, we mainly mean that the person is who he is saying he is. First authentication needs to happen. In the web applications, the login pages authenticate the user if he/she is the owner of that account or not. For authentication we may need a username and a password to prove our identity.

When the authentication is done, the user enters the web application. But he/she may not have access to all the features. Here comes authorization. Authorization let us know what accesses and rights the user has.
For example, if admin is logged in, he/she has access to more number of features than a user.

Now, lets talk about Principal

In Spring security, a user sends a request along with credentials to the server. After the user is authenticated, the returned response contains an Object of Principal which has the details of currently logged in user.

In Spring boot, add the following dependency to use Spring Security :

`<!-- https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-security -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
    <version>3.4.4</version>
</dependency>`

Now, as the dependency is added, do we need to configure something to use Spring security?
NO

After adding the dependency, just try hitting an API and you’ll get Unauthorized.

Spring by default uses Spring security if it is added in the pom file.

Spring Security Default behaviour —

Adds mandatory authentication for all URLs
Adds login form(try opening the localhost url in browser)
Handles login error
Creates a user and a password by default.

Above, the user and password are generated by Spring security. You can find the password in the console logs when you start the application and the user is “user” by default.

Lets now talk about configuring authentication.
Step 1 : Get hold of AuthenticationManagerBuilder
Step 2 : Set the configuration on it.

What kind of authentication you want? eg. in-memory, etc.
Set the user and password

`@EnableWebSecurity
public class myClass extends WebSecurityConfigurerAdapter {
  @Override
  configure(AuthenticationManagerBuilder auth) {
    auth.inMemoryAuthentication()
    .withUser("user1")
    .withPassword("password")
    .roles("USER");
  }
}`

AuthenticatonManager has a method called authenticate() and we use AuthenticationManagerBuilder to access it. Override the configure method which takes AuthenticationManagerBuilder object and then set what kind of authentication you want, set the username and passwords and define the role for that user.
Now, the above code is not correct because the password is in plain text.

Never store password as plain text.

Always deal with hashed password by encoding it.
How to set a password encoder?
Just expose an @bean of type PasswordEncoder because spring security keeps looking for all the beans available to find a password encoder.

@Bean public PasswordEncoder getEncodedPassword() { return new BCryptPasswordEncoder(); }
Now for configuring authorization, we can ovverride same method configure() but with different parameters.

`@EnableWebSecurity
public class myClass extends WebSecurityConfigurerAdapter {
  @Override
  configure(HttpSecurity http) {
    http.authorizeRequests()
    .antMatchers("/**")
    .hasRole("USER");
  }
}`

The above code uses configure method along with HttpSecurity object, which authorizes all the requests given using antMatchers.
Above code, will authorize all the APIs for role USER which means all the APIs are accessible only by USER role.

`@EnableWebSecurity
public class myClass extends WebSecurityConfigurerAdapter {
  @Override
  configure(HttpSecurity http) {
    http.authorizeRequests()
    .antMatchers("/**")
    .hasAnyRole();
  }
}`

Above code lets any role access the APIs.

`@EnableWebSecurity
public class myClass extends WebSecurityConfigurerAdapter {
  @Override
  configure(HttpSecurity http) {
    http.authorizeRequests()
    .antMatchers("/admin").hasRole("ADMIN").
    .antMatchers("/user").hasAnyRole("ADMIN","USER").
    .antMatchers("/**").permitAll().
    .hasAnyRole();
  }
}`

In the above code, the API with /admin can only be accessed by users with ADMIN role, /user can be accessed by users with roles ADMIN and USER and all the other APIs can be accessed by every user.

Note the above sequence, if we put “antMatchers(“/**”).permitAll()” at the top, that would make all APIs accessible to every user, so here the sequence matters.