Manmohan Tyagi

Hi. This is Manmon. I have 15 years of overall experience in IT. I had the opportunity to work in different kinds of domains like healthcare, banking, retail, and payment transactions. So I have expertise in cloud technology, big data technology, microservices, payment transactions, storage domains, and healthcare. Apart from that, I have language-wise experience in Python, Java, Golang, and Scala. Most of the time, I'm playing the roles of a solution architect and a cloud architect. So, my daily activities include designing and reviewing architectures, enhancements, security posture on cloud deployments, and on-premise deployments. I also talk to stakeholders about how to optimize monitoring products, how to deploy new features into production servers, how to maintain infrastructure security, and team management. That's actually my daily activity. On the technical front, I have experience in big data technologies, artificial intelligence, and generated AI, which includes cloud services. As I mentioned, I have 10 years of experience on AWS cloud, 5 to 6 years of experience on GCP cloud, and 2 years of experience on Azure cloud. So, essentially, we developed a security product with VMware, named VSS, VMware Security State. This was a running security posture. For example, we deployed a workflow on cloud, and we wanted to ensure the security posture of our workload on cloud or applications like that. So, that's a high-level introduction about that.

So, actually, there is no single rule that governs how you implement the PCI DSS control in your project. But let me try because I work in many projects where we require PCI DSS compliance throughout. So we were working in my last project with the EPAM system, and at the time, we actually implemented one payment gateway there. So, very high level, actually, there are 12 key requirements for PCI DSS compliance in any project, whether it's on cloud or on premises. If you're on-prem, it's going to give you a favor because you're in your private network. So let me highlight the 12 key responsibilities for compliance in any solution on cloud or on premises. But here are the 12 key responsibilities that we think are most important. PCI DSS involves 300 subcategories of controls. So it's not possible to completely cover all of these, but we're going to highlight the 12 most important things. So, first, from a network security point of view. When we're talking about network security, firewalls come into the picture. So in our environment, there should be a very fine configuration of the firewall installation and firewall configuration. If you're on-prem, then, of course, you have the leverage that you're in your private cloud, so you can manage more fine-tuning. But when you're on the cloud, of course, you have to maintain and choose your firewall properly. Then there's the issue of vendor defaults. If some vendor you're working with is providing a default password or some keys, you'll need to manage these completely. The third thing is that you have data. So, that's how you're going to protect your data, which is both physical and virtual, depending on where you put your data. There should be security measures in place to protect your data, and then there's the encryption of data at rest, where you actually store this data. And in transit, if you're transmitting this data from one point to another, encryption in transit is called, like, HTTP, SSL, or TLS. We have to provide that. Next, point is the antivirus. Actually, our system is not just working as an individual monolithic system. It's a microservice, with many components and modules working together. So, individually, different systems are working collectively. We should have updated policies on how soon we get updated devices for the entire system. So, the next thing that comes into the picture is securing your system and application. What kind of application system you have is also very critical. Now, let's talk about access. We have three kinds of access: access to cardholder data, access to system components, and access to restricted physical areas, like on-premises servers. We should have fine-grained access control policies to determine who's responsible and authorized to access this particular system, application, cardholder data, and restricted areas. Like, if we have on-premises servers, we need to clearly define who's allowed to access them. And a couple of things we can add here are monitoring and logging, and access to network processes and cardholder data for auditing purposes. We should clearly define our security policies according to the organization's policies and the different people working, what kind of privileges they have, and how encryption and these things are working. These are the key things. And, of course, in any project, there are a lot of challenges because it's not just a matter of picking up some notes and implementing them. We also face many challenges in this area, such as how to protect different points of data, how to protect access, and how to protect our systems.

What is said to imply about answering data security and PCI compliance is that it's critical for protecting sensitive information for our financial transactions. So, first of all, when you're using a cloud-based system, like Azure or GCP, you should keep in mind that its services should be PCI compliant. Then you can implement network segregation. It's better to keep the payment system and the nonpayment system segregated, which increases security and facilitates investigations. You can then implement encryption, address transient data, make tokenization to hide sensitive information, and implement the least privileged access principle to control access. Multifactor authentication is also very interesting today, and regular security auditing and monitoring is a critical part. Logging and monitoring are key. An important point is that when working on PCI compliance or data security, PCI compliant assessments should be regularly conducted on the system. These are a couple of things to keep in mind when working on this kind of thing.

How would you design a rate limiting system for high demand payment API to prevent abuse? Before explaining rate limiting, let's discuss what happens when we have a public-facing payment API or payment gateway. There might be cases where cyber attacks or misuse occur. For example, a malicious user may intentionally or unintentionally abuse the payment API repeatedly. To prevent overloading our system, we have rate limiting. For instance, if I'm trying to access a particular payment API gateway online from a specific IP address or continent, rate limiting can be helpful by limiting the number of requests I'm allowed to make. For example, I may be allowed to make only four requests in a minute. In this way, the system functions properly and isn't overloaded or unnecessarily scaled out based on the load. Rate limiting is a way to maintain our scalability in a requirement fashion rather than bundling the system in such scenarios. This is actually a way to rate limit high-demand payment APIs to prevent abuse. Another way is to prevent robotic or DDoS attacks. In this scenario, the system is behind a load balancer, and the auto-scaling features are working to meet the demand. To prevent these unexpected side effects, we again implement rate limiting at a level to prevent and stop or allow very limited issues in our system.

So, actually, the process we implement to validate and deploy massive changes to the payment system without affecting the user is very critical. It involves three key things. First, the user experience. Second, the system should be functional in any case of deployment, whether it's a message deployment or any kind of deployment. Here are some techniques that we can use. First, we have our environment, such as a production system, and we are going to make a massive deployment. A better strategy is to deploy first into a staging environment, development environment, or testing environment, rather than directly to the production environment. This way, we can deploy and monitor the system's behavior, detect any errors or functional failures, and see how the system will behave. Then we can use a canary deployment. For example, when there's a message deployment, we want to test it in real-time or in a real environment. In this scenario, we can redirect a small percentage of traffic to the newly added feature or deployment. This is a way to test the functionality without affecting the entire system or the user experience. Once you're deploying the things, monitoring and logging are very important, as is security. Then, a major thing is to have a rollback policy in place. If any kind of thing fails, we need to know how to roll back the entire system or rebuild it to its previous state, so it functions properly and the user experience is not impacted. Another way we can use is a feature toggle. For example, when we're deploying a message deployment, we can toggle off that functionality if it's going to break the system. We can do this at a later time, and the rest of the system will continue to work fine. Before deploying into production, we should do an impact and risk analysis, and this should be properly documented. Teams should be aligned, and we should inform stakeholders about the kind of change the system will be deployed, what might be the known issues or hidden issues, and how we have rollback policies in place to control the system in its previous state. These are the summary.

Optimize database transaction in high throughput payment processing to avoid contention. There is a technique. In such scenarios, we have already utilized a large number of users across different continents or geographic locations. Of course, there are local demands. Therefore, we need to optimize database transactions in high throughput environments. To avoid resource contention, there are other techniques. Like, for example, we can use a database replica. In that scenario, the load will be balanced, as there is a load balancer that distributes the load, and we have multiple database replicas. This might be your read replica for read-intensive commands. You can also have a master and replica architecture. In some scenarios, if our master fails, then the standby will take over. A read replica is a way to scale the system, so that all read commands hit the replicator rather than the actual system. The second thing is distributed caching. You can use a cache here, which will also prevent or reduce the load on our system. We can use proxies and connection points, so that the actual database server has to handle less load. Some load will be handled by the distributed cache because the answers are already there, the reader replica will work, and the proxy will work. We have a standby system. These are the things we can use to optimize our payment processing system to avoid resource contention. Since only a few requests, like read, update, or delete, are mandatory for our database, we can already leverage the reload system. The system has a buffer and resource capacity available in that scenario, so that's the way to optimize. To achieve full tolerance and high availability, we can deploy a parallel system across multiple zones or regions with complete data backup policies. Our system should be functional in any kind of failure or situation. These are the techniques.

JOS JOSA Java code snap explained why class might not be following the single responsibility principle. How would we factor it to adhere to the better design? So, here's the payment processor. We have a process method. Then log transaction, send a receipt. Here is the payment data. So, look, according to the SOLID principle, single responsibility is going to say that whatever the responsibility we have, just keep it out in either an interface or an abstract class, then try to implement it in our concrete class or some payment process. Because if the system is going to be extensible, like we have three or four methods here, and someone's class is going to then implement it, so it's not going to break the system. So, single responsibility means only one responsibility. So here, we have three methods: process payment, log transactions, send a receipt. What we can do is separate the responsibility: process payment in one interface and send receipt in another interface, so that the class responsible will work accordingly. And we have now single responsibility processing payment in one interface, one class is responsible for this, another guy is working on the receipt sending, and the third one is going to log the transaction manage. So we can just divide this and assign to the single interfaces. So, any of the concrete class or in case of tomorrow, we want to extend the system, it's not going to break all effects because there are a number of separate interfaces. For example, tomorrow, we are extending the system, but our system only requires sending a receipt. So we have to implement only the receipt sending, not the process and maintain the transactions. So keep it separate in separate interfaces that meet our single responsibility, SOLID design principle to be better.

Given this, it's a strategy pattern. Actually, in what will be done is open, close. Okay. So we have a payment context. Here, we have an interface. I payment strategy. We have a pay method here. So in payment context, we have a private variable. Okay. We will define this high payment strategy variable. Then we have two methods here, process payment. Okay. That's fine. Processing the payment. Set payment strategy means dynamically we want to change the strategy. For example, today, credit card, PayPal, or Bitcoins. There might be different kinds of implementation. So the question here is open close. So I think the interface should be single one. That's correct. And the credit card payment implemented this interface. It has a separate implementation. Okay. That's great. Then here, we have more payment strategies. So in that scenario, like, Bitcoin or PayPal or another kind of payment strategy might be. So here, the interface is clear. The implementation for this credit card or different strategy is clear. Come to the payment context class. So in payment context class, we have three things. 1 variable that, of course, going to set the payment registry dynamically at runtime. Process payment. Okay. Going to pull the pay. That's right. So I think that, here is the missing one thing. We should have a default strategy in payment context, and that we can achieve by using the constructor. So we should implement one constructor in payment context, and let's set there the this payment strategy variable to set. So, like, in any of the clients, in case of the client is going to call, so it's going to the instances like credit card payment or some other to make the payment. So the constructor is going to call to create the instances. So my understanding is here, it should have the constructor with the setting of payment strategy. So that thing is the missing here. I think that can be achieved.

What measure would you take to prevent transactional data loss during a system failure? Okay, so the question is to prevent transactional data loss during a system failure. There are many ways to prevent transactional data loss. First, we need to understand that our payment system is a distributed transactional system. Is it going to use distributed transactional coordination? Is compensating transaction available? So that in any case, we can roll back the system. The third thing is that the system is idempotent. What kind of communication is that? Asynchronous or synchronous communication? What is the monitoring and logging strategy we have there? The fourth thing is that there should be retry and time out. In a system failure, to prevent data loss, we should have a proper backup and restore strategy in place. Even if the system partially fails, our data won't be lost. There are two types of data: transaction log data and actual transaction data. Regardless of the storage system, we use, for critical data, it should be replicated in multiple storage systems. Our storage system, like I mentioned the relational database, should be duplicated in different regions or zones so that both systems are synchronously updating the state. In any failure scenario, the system may fail, and the journal or region may fail. But our system is in a condition to be functional and recoverable. So, backup and policies, database replications, multi-regional deployment, and storage replication as well. Load balancing and DNS routing are also important. These are the things that we can do to prevent data loss during a partial system failure or complete system failure because of multiple things, database backup, restore, we can get back to our system in a functional state, or we can say we can recover the system.

To use cloud services to manage and analyze payment transaction logs or performance tuning. So, this is one of the many services that public cloud providers and private cloud providers offer. So, I'm taking the example from AWS side. So, let's talk about this. First of all, there's the data injection. So, inside of data injection, let's stream all of your transaction logs to the AWS S3 service. It's going to be in real-time or in a batch, whatever the requirements are. And keep in mind that the system should support the API or some SDK to ingest the data in a single, centralized place, like AWS Lake Formation. Then, the second thing is how we're going to cleanse and transform the data. So, in that case, AWS provides the AWS Glue service, and, of course, there's the catalog as well. So, we can utilize the AWS Lake Formation for data cleansing and data catalog as well. The third thing is the analysis purpose. This is Athena. So, Athena allows you to use an interactive query. You can find insights in your logs, what kind of queries you have, and understand your transaction log system. Then, there's the Cubesight. Cubesight is an AWS service that helps you create a dashboard and visualization. If you want to do advanced analytics, then there's SageMaker. SageMaker is a machine learning model itself for predictive analysis or some detection kind of things if we have security logs. Then, there's the monitoring and logging services, like CloudWatch. Then, for optimization, you can create your performance metrics based on some parameters, like personalization or response time. So, whatever kind of metrics you want, you can create on CloudWatch, AWS Cloud. What's then is the cloud grid for testing your system, to see how many types of requests are going to the system, and auditing purposes. So, these are the services. I just took the example from AWS cloud itself. So, these are the services available that we can use.

Incorporating an automated security scan within the payment processing application deployment life cycle involves several phases. For instance, there is the authentication part and the authorization part, which includes the list of privileges your application will access in the database. When storing data in storage, it's essential to make it compliant, such as PCI DSS compliant, and secure it. To implement controls, you can leverage automation. In my previous project, we implemented this using the Robot Framework with Python. Regardless of whether you're deploying on-premise or in the cloud, encryption, access controls, physical security, tokenization, and masking, such as video, TLS, or SSL, are necessary. You can write test scenarios in the Robot Framework to automatically scan your application in the dev, staging, or testing environment, evaluating the security posture and scanning end to end to ensure compliance. The security level should be guided by existing roles and responsibilities. To automate security scanning at the time of build or in CICD pipelines, you can make this process automatic throughout the deployment life cycle.