How we achieve our 25ms p95 response time SLA? 1. Local-first security The first step to fast response times is processing as much as possible locally. Although your interaction with the Arcjet SDK is in JS, most of the analysis happens inside a WebAssembly module. We bundle this with the SDK, and it runs in-process without requiring any additional software like Redis or an agent. 2. A low-latency gRPC API in every cloud region Not everything can be analyzed locally. Rate limits need to be tracked across requests, and we operate an IP reputation database. This is all handled via our API. If a decision can’t be taken locally, then our API will augment the analysis with a final decision. As this blocks requests to your application, we set ourselves a p95 latency goal of 20ms, with an additional few millisecond allowance for network latency. This means it needs to run in the same cloud region - we’re currently deployed to 22 different regions. 3. Persistent HTTP/2 connections The slowest part of making a request is often establishing the initial connection. A normal TCP handshake requires 1 round trip, and the TLS handshake requires another 2. If a round trip takes just 1 ms, then that’s easily 3 ms taken up just opening the connection. Then the API request requires another round trip. A few months ago, we introduced support for multiplexing requests over a persistent HTTP/2 connection. When the Arcjet SDK is instantiated, we open a connection to our API and then keep that connection open over multiple requests. 4. Smart caching If a client request is denied, then the chances are their next request should probably also be denied, but it depends on which rule caused the deny decision. This is where our smart caching comes in. When an email verification request results in a deny, that should not be cached because it may be because the user made a typo. Their next request should be freshly re-evaluated. But if it’s a rate limit rule that denies a request, we can look at the configuration to determine whether another request is going to result in another deny. Not only do we consider whether they are already over the rate limit, the time to cache the result is determined by the rate limit configuration. If the limit applies for a fixed window over the next 30 seconds, then we’ll cache for 30 seconds. Results The result is our p95 API response time of around 25ms, which is within our goal range of 20-30ms. Our p50 is around 4ms, but we pay more attention to the outliers revealed by the p95 because those are what cause real user experience degradation.
Arcjet’s Post
More Relevant Posts
-
Using an S3 bucket and Cloudfront for CDN is a quick and easy way to get your static website up and running with a good user experience. Users interact with Cloudfront which gets its data from the S3 and caching helps a lot with latency. One key thing you need to make sure though from a security perspective is to not allow end users to directly access the data in S3. This article from Pankaj Makhijani shows how you can ensure this is handled securely. For the latest approach on AWS you also likely want to look at Origin Access Control (OAC) from Cloudfront which you can easily migrate to from the Origin Access Identity (OAI) setup described here. https://lnkd.in/eG4pRAW9
To view or add a comment, sign in
-
Anger, frustration, anxiety. How did you spent your last 2 weeks? I have been debugging a memory leak that became visible in a central productive identity and access management service serving millions of users. We did an upgrade from spring boot 3.1 to 3.2. Took ages to figure out the specific spring library that was causing this and then to boil it down to specific code changes in the spring library. How did they come up with adding a local in memory storage in 2024 where cloud and distributed systems are the most common thing? Maybe this also fixes your memory leak in spring? Proud of the finding and the bug report in spring security. Especially in finding something that has not been answered thousands of times in the www. Hope this prevents future human headaches.
Spring Security 6.2 defaults to InMemoryOidcSessionRegistry causing memory leaks in distributed systems with external session storage · Issue #14558 · spring-projects/spring-security
github.com
To view or add a comment, sign in
-
I've just been bitten by a "supported but not supported" feature from AWS. CloudFront started supporting access control for Lambda function URLs. They published a news article about how it's going to help everyone securing Lambda functions: https://lnkd.in/dpnmBcQg What I noticed is that POST requests don't reach the function, only GET and HEAD. I then went with the usual suspects: what's the path pattern, are all HTTP verbs enabled, is the correct OAC added to the origin, is the Lambda permission added to the function, and so on. Everything checked out. Then I found this article that describes the same problem I faced: https://lnkd.in/dcKd7YQ3 > But when I attempted a POST request, it failed with the following error message Then, of course, the documentation mentions this: https://lnkd.in/d_zHgCYg > If you use PUT or POST methods with your Lambda function URL, your user must provide a signed payload to CloudFront. Lambda doesn't support unsigned payloads. That's business-speak for: request body is not supported. That's a bummer. Have a Lambda function to provide an API behind CloudFront? OAC is not a solution then as you'll need POST requests with a request body sooner rather than later. To be honest, after this I don't see any real-life use-case for Lambda OACs. So going back to the secret header.
Amazon CloudFront now supports Origin Access Control (OAC) for Lambda function URL origins
aws.amazon.com
To view or add a comment, sign in
-
Developing scalable APIs to support growing demands? Here are three common challenges and solutions: 1. Handling High Traffic: As the number of users and requests grows, APIs can become overwhelmed, leading to slow response times and potential outages. Solution: Implement load balancing to distribute incoming traffic across multiple servers, ensuring no single server is overwhelmed. Use auto-scaling features in cloud platforms like AWS or Azure to dynamically adjust resources based on traffic patterns, maintaining performance and availability. 2. Efficient Data Management: Large datasets can slow down API performance and complicate data handling. Solution: Optimize database queries and use indexing to speed up data retrieval. Implement caching strategies with tools like Redis or Memcached to store frequently accessed data in memory, reducing the load on the database and improving response times. Additionally, consider using pagination for large datasets to manage and present data more efficiently. 3. Security and Rate Limiting: High traffic can increase the risk of security threats and abuse. Solution: Implement robust authentication and authorization mechanisms using OAuth2 or JWT to secure your APIs. Use rate limiting to control the number of requests a user can make within a given time frame, protecting your API from abuse and ensuring fair usage. Tools like API gateways (e.g., Kong, NGINX) can help manage these aspects effectively. Please let me know in comment and let us engage to discuss more. ********** DM | Follow Nageswara Rao Korrapolu for Building a Better Technology for a Better Future. Thank you very much. #microservices #DigitalTransformation #Migration #TechnologySolutions #cgm
To view or add a comment, sign in
-
InterPlanetary File System (IPFS) — https://ipfs.tech/ — is an open-source project that is building a peer-to-peer file system. The IPFS project is an ambitious project that can potentially change the way we use the Internet. Its final goal is to connect all devices that have the same file system, but not in the same way the Web does today. In order to understand the basics of IPFS, it’s helpful to compare it with HTTP. Essentially, the current World Wide Web is based on the HTTP and HTTPS protocols. In short, these are application protocols that enable worldwide data communication and accessibility. HTTP works as a request-response protocol that connects users (clients) to servers, based on their location. For instance, if Alice goes to a website, her web browser will request the content to the hosting server (e.g., Amazon Web Services). If all goes well, the AWS server will then return the web pages to her. However, the content is not permanent because it is maintained by a centralized server. And since the AWS is hosting a large number of websites, if their servers go down for any reason, a big percentage of the Internet goes down with it. In contrast, IPFS allows for the creation of a permanent and distributed Web, where all sorts of digital data can be stored and shared. While HTTP communications rely on a server (with a specific location) to provide the content, IPFS communications focus on the content itself. With IPFS, Alice would no longer ask the content directly to the AWS server. Instead, she would ask the distributed network “who can provide me this content?” and the closest peers would quickly respond. Depending on the implementation, IPFS may present many advantages when compared to HTTP, such as censorship resistance, data integrity, lower operational costs, better performance, and security. Some of the limitations are related to the low incentives to participate in the network, which leads to a small population of peers. The limited adoption makes it harder for files to be permanently available. If certain data is only hosted by a handful of nodes and all go offline, it will become inaccessible. — From: https://lnkd.in/dFbwhG-D
To view or add a comment, sign in
-
Enhance the security of your #NestJS application by enhancing the configuration service to retrieve values from Azure Key Vault using custom providers instead of local .env files. In this article, I elucidate the process of constructing a custom provider to access Azure Key Vault values, thereby augmenting the capabilities of the default config service in #NestJS. Don't miss out on this insightful read! 🚀 #NestJS🔗 https://lnkd.in/gYcCphi5
Unlocking Security: Seamlessly Integrating Azure KeyVault with NestJS Config Service
medium.com
To view or add a comment, sign in
-
6-Year-Old: "Hey, what's a CDN? I heard it makes the internet faster." Software Techie: "Oh yeah, it's like having a bunch of superheroes who help deliver stuff on the internet, making it quick for everyone." 6-Year-Old: "Superheroes? How do they do that?" Software Techie: "Well, imagine you have a cool toy, and your friends want to play with it, but they live far away. So, you give the same toy to your friends who live closer to them. That way, when your friends want to play, they can get the toy from their nearby friends super fast!" 6-Year-Old: "Oh, so the CDN is like a bunch of friends with the same toy, but they live closer to us and help us get the website stuff faster?" Software Techie: "Exactly! The CDN is like friends with copies of websites and videos in different places. When you want to see a website, you get it from your closest friend (or server), making the internet faster." 6-Year-Old: "Wow, that's cool! Thanks, superhero friends!" Software Techie: "You're welcome! They're our internet heroes, making things faster and better for all of us!" CDN is a group of proxy servers distributed across the world. They are placed on the network edge. CDN helps in making the product faster, reduces the overall latency, and enables data-intensive applications, making them highly available, scalable, reliable, and secure When an end-user accesses an application, the request is routed to the nearest CDN using the routing system. There are scrubber servers that help to filter the malicious traffic and reroute requests to the CDN. The distribution system is vital in distributing the contents to all the global CDNs. The management system is like a monitoring system that measures important metrics like latency, load, downtime, and others. Origin server sends the data to all the Parent proxy servers, which distributes the data to all the child proxy servers. End users consume to get the data from the child proxy servers. This tree-like structure helps in faster distribution, scalability, and reducing the load during content distribution. How an end user is routed to the nearest CDN to serve the content is optimal and vital. Various methodologies are employed, like DNS redirection, routing systems like Anycast, client multiplexing, HTTP redirection, and many others. The CDN should never redirect a user to a distant server or reroute them when the CDN is overloaded. CDN has various advantages; it helps with the overall system, improves its availability, scalability, reliability, security, latency, and distribution load, and reduces the page load time and bandwidth. Various scenarios benefit from leveraging CDNs, including video streaming, multi-user scaling, serving static and dynamic content, large software and gaming downloads, high-speed content delivery, real-time streaming, and numerous other applications. Overall, having an in-depth knowledge of CDN is essential. #systemdesign #cdn #cloudfront #engineering
To view or add a comment, sign in
-
Yesterday, I concluded the project i was working on. My team and I developed a full-stack application on Google Cloud Platform (GCP) in compliance with HIPAA regulations. As the Cloud Architecture Engineer and team leader, I was responsible for designing the architecture and overseeing the deployment of the project, with a strong focus on scalability, security, and regulatory compliance. I began by structuring the database for deployment into GCP’s SQL server, ensuring it was optimized for both performance and HIPAA standards. In terms of networking, I created a Virtual Private Cloud (VPC) to segment the application architecture. Within this VPC, I designed subnets for the backend and frontend servers. To regulate traffic, I configured firewalls to control ingress and egress, allowing only essential ports (8080 and 22) for the backend server. Security compliance was critical throughout the project. I ensured all HIPAA security requirements were met by implementing firewalls and enforcing Cross-Origin Resource Sharing (CORS) policies, allowing only the frontend server to interact with the backend server while tightly managing external access to the backend. For the backend, I created a virtual machine named backend-server and installed necessary dependencies, including the MySQL client, to ensure seamless interaction with the database. I also established secure communication between the backend and database servers using VPC peering. For the frontend, I deployed a virtual machine within its own subnet, configuring firewall rules to permit traffic through ports 3000, 443, and 22. Finally, I provisioned the frontend server’s name to be configured in the DNS zone to enable seamless access and proper name resolution. #cloudsecurityengineer #cloudarchitect #securitycompliance #scalableandreliable #HIPAACompliance
To view or add a comment, sign in
-
AWS Application Load Balancer introduces header modification to enhance traffic control and security. This feature offers three key capabilities: 1. Header renaming: Like renaming a package labeled "Confidential" to "Regular Package" to avoid attention, AWS ALB can rename complex technical header information to more understandable names. 2. Header insertion: Just as you might add a note to a package instructing the recipient on how to open it, AWS ALB can add new headers to requests or responses to provide additional information to applications. For instance, insert a CORS header to allow applications from different domains to access your application. 3. Header disabling: Similar to removing an unnecessary note from a package, AWS ALB can remove unnecessary headers to minimize security risks. For example, disabling the "Server" header to conceal information about your operating system and web server version. For more details, visit: https://lnkd.in/gwFd2QN8 #AWS #amazonwebservices #awsvn #awsvietnamusergroup
AWS Application Load Balancer introduces header modification for enhanced traffic control and security - AWS
aws.amazon.com
To view or add a comment, sign in
-
Feb 29 - How internet works ? (1/n ) Lets say we want to access www.delicious.com , now here the client is your system and server is the delicious com server Client - web server / mobile web page / mobile app or whoever requests the information they are client. So client makes a request to www.delicious.com , client is in russia and server is in india, they will interact over the internet So to interact with the server we need the address which is IP address ( we can relate it to the amazon delivery, just like how amazon needs you home address to deliver the product) We use port, using this port we know which process to communicate to ( just like in the address you have mother father brother and you living but with the name on the package we know who does the package belongs to ) so with the port we know which process to communicate. ipaddress:port this is also called as Socket Address. MAC address is physical identification of computer , MAC address doesn’t change. We have URL , but we need an IP address So there’s a process called DNS, Domain Name Server we can say that this is a system gets the IP address corresponding to the URL So we communicate to DNS if we want the IP address. What is the architecture of DNS ? https://lnkd.in/gCvjMWPT Inside the URL we have the protocol http or https these are protocols. Protocols are nothing but rules and regulations that are imposed based on what kind of communication we need to do. http is used to transfer any kind of hypertext. For file transfer we have ftp Shell connection - ssh Host address - cs144.scs.stanford.edu Internet doesn’t understand host address , In early days didn’t had DNS we had hosts.txt file in that we have URL to IP address mapping. Network Information Center used to manage hosts.txt file. Hosts used a FTP to download a new version ( because every day new urls are created ) This was not scalable. Hosts.txt has become less manageable. Lets say if website ip address has been changed then we need to manage hosts.txt file. Later Domain Name server was introduced A DNS architecture is kind of like a tree based architecture. From your machine it will check hosts.txt whether we have corresponding ip address for the URL we needed, if not then we communicate with ISP, within ISP we have access to DNS, if there is no record found then it redirect to the tree based architecture. Records for all .com is found in .com server , same for .in, .edu, org. So thats how DNS works now a days. ( its kind of saving a number for the first time, then next time we can access it by the name ) Sanket Singh Riya Bansal Algocamp #sanketsingh #algocamp #feb29 #100daysofcode #365daysofcode #javascript #network #autoscaling #manualscaling #caching #loadbalancer #http #https #dns #domainname #tcp #udp #tcpip #osimodel #applicationlayer #networklayer
To view or add a comment, sign in
420 followers
More details: https://blog.arcjet.com/how-we-achieve-our-25ms-p95-response-time-sla/