That’s where non-functional requirements (NFRs) come into play.

Non-functional requirements define the quality attributes of a system: its reliability, responsiveness, scalability, flexibility, and more. These aspects don’t deal with features directly but ensure the system delivers a robust experience.

Here are 8 essential non-functional requirements that every developer should know—along with how to implement them in practice.

1 - Availability

What it means:

Availability ensures that your system is operational and accessible when users need it.

Why it matters:

If your system goes down during peak usage (e.g., an e-commerce flash sale), you risk losing revenue and user trust.

How to implement:

Use Load Balancers (like NGINX, HAProxy, or AWS ELB) to distribute incoming traffic across multiple instances of your application. This ensures that no single failure point can bring the whole system down. Combine this with health checks and failover mechanisms for maximum availability.

2 - Latency

What it means:

Latency is the time it takes for a user’s request to receive a response. Lower latency equals faster, smoother user experiences.

Why it matters:

Users won’t wait forever. Studies show that even a 100ms delay can impact user engagement and conversions.

How to implement:

Deploy a Content Delivery Network (CDN) like Cloudflare, Akamai, or Amazon CloudFront to cache static content closer to the end user. This reduces travel time for requests and significantly speeds up asset delivery.

3 - Scalability

What it means:

Scalability is the system’s ability to handle increasing workloads by efficiently adding resources.

Why it matters:

Your app may work great with 1,000 users, but what happens when it hits 1 million?

How to implement:

Use data replication to distribute load across multiple database nodes. Combine this with horizontal scaling for stateless services using container orchestrators like Kubernetes. Design APIs to handle concurrent users gracefully.

4 - Durability

What it means:

Durability ensures that once data is stored, it remains safe—even in the case of power loss, crashes, or system failures.

Why it matters:

If users lose their transaction history, passwords, or saved preferences, your app loses credibility.

How to implement:

Use transaction logs or write-ahead logs (WAL) to persist operations before applying them to the database. Systems like PostgreSQL and MySQL have this built in. In distributed storage, use replicated, fault-tolerant data stores like Amazon S3, Cassandra, or HDFS.

5 - Consistency

What it means:

Consistency means that users see a reliable and accurate state of data—even when multiple servers or databases are involved.

Why it matters:

If user A updates their profile but user B sees outdated data, that’s a poor experience.

How to implement:

In distributed systems, eventual consistency is often used instead of strict real-time consistency. Systems like DynamoDB and Cassandra ensure that all nodes will eventually reflect the same data. Use conflict resolution strategies and data versioning when needed.

6 - Modularity

What it means:

Modularity means breaking down the system into independent, manageable components.

Why it matters:

Tightly coupled systems are hard to scale, test, or modify. Modularity gives you agility.

How to implement:

Follow principles of loose coupling (components interact via interfaces or contracts) and high cohesion (each module has a single purpose). Use design patterns like microservices, layered architecture, or hexagonal architecture to promote modularity.

7 - Configurability

What it means:

Configurability allows you to modify system behavior without deploying new code.

Why it matters:

Want to enable a new feature or change system behavior across environments (dev, test, prod)? Doing this without code changes is a big win.

How to implement:

Use Configuration-as-Code with tools like Terraform, Ansible, or Helm to manage infrastructure settings in version control. Also, expose runtime configuration via environment variables or centralized config servers (e.g., Spring Cloud Config).

8 - Resiliency

What it means:

Resiliency is the system’s ability to recover gracefully from faults or disruptions.

Why it matters:

Failures are inevitable. What matters is how well your system handles them.

How to implement:

Introduce message queues (like RabbitMQ, Kafka, or AWS SQS) to decouple producers and consumers. This allows parts of your system to fail or restart without losing data. Also use circuit breakers, retry logic, and backoff strategies to handle transient issues.

👉 So - which other NFRs will you add to the list?

Leave a comment

That’s it for today!

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

Have you ever struggled to explain a tech concept to someone who has never seen a line of code in their life?

Yes, we have all been there at some point or the other.

It may be hard for a new developer to imagine, but a large number of your colleagues are going to come from a non-tech background. And you need to interact with them every now and then. In some roles, this interaction will be extremely important.

However, one thing is certain.

If you want to grow as a developer, you must learn how to talk tech stuff with non-tech colleagues.

Trust me - this is the key to your success, whether you are in an organization or if you are running your own freelance business.

But frankly speaking, it’s not as tough as we make it out to be.

Over the years, I have always relied on what I call the Communication Iceberg to get my ideas across as effectively as possible. The iceberg contains many tools for abstracting the technical stuff while engaging with non-technical folks in what can sometimes be career-defining interactions.

However, it’s important to understand when and how to use these tools. And that’s what we will be covering in this post.

For better clarity, I have divided the tips into two categories.

1 - The General Tips

Some things that you must do at a bare minimum while explaining programming concepts to a non-tech audience:

• Use analogies - Instead of using terms like servers and requests, try relating them to real-world examples such as waiters and orders in a restaurant.

• Avoid acronyms and jargon - Wherever possible, use plain language to explain a concept instead of an acronym or jargon.

• Explain stuff visually - Use visual aids such as flowcharts, diagrams or graphs instead of long-winded explanations.

• Use storytelling - Everyone loves stories. They are powerful tools to capture the attention of a non-tech audience. For example, instead of saying version control, build a story of a team of developers sharing their code and tracking changes.

• Focus on the big picture - Don’t jump into the deep end of a tech concept. Try to start with the big picture and ease your non-tech audience into learning more about complex topics.

• Encourage questions - Don’t be a robot while explaining a concept. The more questions you can encourage people to ask, the more you will be able to get them involved and make them understand the topic.

Here’s a diagram that can help you make more sense of these strategies

2 - Role-Specific Tips

The general tips can take you a long way.

But an organization is made up of many roles. People come from different backgrounds. They have different goals to achieve or agendas to pursue depending on their position.

I have experienced that it can be extremely fruitful to understand your audience better and tailor your message accordingly.

Here are a few tips that can help you out with specific roles.

Managers

When you talk to a manager, try to focus on the business impact of your technical work.

Always use data and metrics to push your point rather than plain old conviction.

Instead of saying:

“We need to use this technology because it’s so good and futuristic”

Try proposing:

“By implementing this new technology, we are able to save the company $50,000 in operational costs each quarter, while also increasing our efficiency by 20%. These savings can be reinvested into other areas of the business to drive growth.”

Here’s a more detailed schematic on how you can go about gathering this information by involving various stakeholders.

Sales Team

A sales team is interested in one thing - selling stuff. When communicating with them about your technical work, focus on how it helps them achieve their goals.

Here’s an example:

“Our new software upgrade will enable your sales team to access customer data in real-time, providing them with the insights they need to close deals faster.”

Following this approach directly links your software with their KPI and increases their chances of funding your project.

Clients

Clients are like potential buyers for your technical product. They might be the reason for your product’s existence in the first place.

When communicating with clients, avoid technical jargon and use plain language to explain your work. Focus on the end results and how your work will benefit the client.

Instead of saying:

“We’re using AWS Lambda to create serverless functions.”

Try saying:

“We’re building a system that can handle millions of requests without worrying about server capacity, which means your application will run smoothly with minimal downtime.”

Get into the technical jargon after you’ve sold the main benefit, and only when it is really required.

General Audience

As a software developer, you might need to share your knowledge and experience with a hall full of people. In such cases, you can’t automatically count on the audience to know about your area of expertise.

When communicating with colleagues who may not be familiar with your area of expertise, try to use analogies or real-world examples to explain technical concepts.

For example, explaining API security to someone who’s not familiar with the area is tough.

Try to create analogies like comparing it to locking your front door to keep burglars out. It’s the same idea, but instead of a physical key, you introduce a special code and create a mental picture for your audience.

👉 So, which other tips or strategies will you add to the list?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

That’s why smart teams follow specific transition patterns. These patterns help reduce risk, maintain stability, and allow the system to evolve gradually rather than completely rebuild.

Here are 4 such patterns that can help you:

1 - Strangler Fig Pattern

The Strangler Fig Pattern is perhaps the most famous strategy for modernizing monolithic systems. It’s inspired by how a strangler fig tree grows around an existing tree, eventually replacing it.

How It Works:

• An API gateway or proxy is placed in front of the monolith.

• New features or refactored versions of existing features are developed as independent microservices.

• The gateway routes requests:

  • To the monolith for old functionality.

  • To the new microservices for updated functionality.

• Over time, as more functionality is moved out, the monolith shrinks until it can be retired.

Why It’s Powerful:

• Incremental migration with minimal disruption.

• Reduces the big-bang rewrite risk.

• You can prioritize extracting high-value or high-risk components first.

Real-world use: Many enterprises use this approach when dealing with legacy systems where complete rewrites would be risky and expensive.

2 - Parallel Run Pattern

The Parallel Run Pattern involves running the old monolith and new microservices together for a period of time. Instead of replacing immediately, you redirect a portion of traffic to microservices to validate their behavior.

How It Works:

• Both the monolith and the new microservices are deployed simultaneously.

• Certain user requests or workflows are mirrored or split-routed:

  • Some go to the monolith.

  • Some go to the microservices.

• The output or behavior is compared to ensure that the new system is functionally equivalent.

Why It’s Useful:

• Catch errors early before full migration.

• Allows thorough real-world testing.

• You can gradually increase traffic to the microservices as confidence builds.

Pro Tip: Use feature flags and automated comparison testing to make this process smoother.

3 - The Collaborator Pattern

The Collaborator Pattern is a clever way to augment the monolith without touching its core logic immediately. It allows you to extend the system by attaching microservices around it.

How It Works:

• Instead of replacing a functionality inside the monolith, you decorate or wrap existing modules with microservices that add new features.

• The monolith still handles the original core behavior.

• Microservices add enhanced behavior, enrich responses, or intercept and modify calls.

Why It’s Valuable:

• Minimal disruption to the monolith.

• Let’s you introduce new functionality faster without waiting for core refactoring.

• Helps test microservice integration with live traffic early.

Example: Suppose you have a monolith that processes orders, but you want to add a new discount service. Instead of modifying the order logic, you add a microservice that “decorates” order responses with discount information.

4 - Change Data Capture (CDC)

One of the biggest challenges during a transition is data synchronization. Change Data Capture (CDC) provides a solution by streaming real-time database changes from the monolith to the new microservices.

How It Works:

• Tools like Debezium, Kafka Connect, or AWS DMS monitor the monolith’s database transaction logs.

• Whenever a change happens (insert, update, delete), the change is captured and streamed to interested microservices.

• This allows microservices to react in near real-time without needing tight coupling to the monolith’s database.

Why It’s Critical:

• Enables event-driven architectures during the transition.

• Allows microservices to maintain their own data stores based on monolith changes.

• Reduces reliance on synchronous API calls to the monolith.

Important Tip: Be cautious about schema evolution; changes to the monolith database schema must be carefully coordinated with CDC consumers.

How These Patterns Work Together

Transitioning from a monolith isn’t about choosing just one pattern—it’s about orchestrating them together:

• Start with the Strangler Fig to route traffic intelligently.

• Run critical paths in parallel to build trust in the new system.

• Decorate existing functionalities to add features without destabilizing the core.

• Stream changes using CDC to gradually separate data ownership.

So - have you used any of these patterns?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

As traffic to your application grows, Kubernetes offers several built-in and customizable scaling strategies to keep your system responsive, efficient, and cost-effective.

In this article, we’ll explore the most essential Kubernetes scaling strategies you should know.

1 - Horizontal Pod Autoscaling (HPA)

This is the most commonly used scaling method in Kubernetes.

The Horizontal Pod Autoscaler (HPA) automatically increases or decreases the number of pod replicas in a Deployment, StatefulSet, or ReplicaSet based on observed resource usage. Most often, it watches CPU utilization, memory usage, or even custom application-level metrics like request rates.

Example:

If you set a target CPU utilization of 70% and your application crosses that threshold consistently, HPA might spin up more pod replicas to balance the load.

Key Benefits:

• Keeps applications responsive during high traffic.

• Scales down during idle periods to save resources and cost.

• Works well for stateless workloads like web servers, APIs, etc.

Things to Watch:

• Requires metrics server to be installed in the cluster.

• Doesn’t handle increasing pod resources—only the number of pods.

2 - Vertical Pod Autoscaling (VPA)

Where HPA adds or removes pods, Vertical Pod Autoscaling (VPA) focuses on resizing the pods themselves.

VPA automatically adjusts the CPU and memory requests/limits for each pod based on its actual usage. This is especially useful for workloads where scaling out is either inefficient or impractical—such as batch jobs, data processing, or single-instance services.

Example:

If your application consistently uses more memory than allocated, VPA can increase the memory limits so the pod doesn’t get OOM-killed (Out of Memory error).

Key Benefits:

• Prevents over-provisioning or under-provisioning of resources.

• Helps optimize performance for memory-heavy or CPU-intensive tasks.

Things to Watch:

• Restart of pods is often required for VPA to apply changes.

• Doesn’t work well with HPA simultaneously unless specifically configured.

• May lead to high memory usage if not monitored properly.

3 - Cluster Autoscaling

While HPA and VPA manage scaling at the pod level, Cluster Autoscaler takes care of scaling at the infrastructure level—specifically, the number of worker nodes in your Kubernetes cluster.

When pods can’t be scheduled due to resource shortages (e.g., not enough CPU or memory across nodes), the Cluster Autoscaler works with your cloud provider (like AWS, GCP, Azure) to add more nodes. Similarly, if some nodes are underutilized and their pods can be moved elsewhere, it can safely scale the cluster down.

Example:

If a new workload comes in and there’s not enough room on current nodes, the autoscaler adds a new node automatically.

Key Benefits:

• Handles infrastructure elasticity based on demand.

• Complements HPA by ensuring there are enough nodes to host additional pods.

• Reduces costs by removing idle nodes.

Things to Watch:

• Needs correct configuration of node groups and cloud provider APIs.

• Works best in cloud environments with auto-provisioning support.

Conclusion: Choose What Fits Your Workload

Kubernetes provides a flexible toolbox for scaling. Here’s a quick summary:

• HPA is great for stateless, load-balanced apps.

• VPA is ideal for apps with unpredictable or variable resource needs.

• Cluster Autoscaler ensures infrastructure scales with your workloads.

So, which scaling strategies have you used?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

A modern production web application is more than just code deployed to a server—it’s a carefully designed ecosystem with various tools and components working together to ensure speed, resilience, observability, and scalability.

Here’s a breakdown of the essential components that make up a production-grade web application.

1 - CI/CD Pipelines

Every production-ready system starts with Continuous Integration and Continuous Deployment (CI/CD) pipelines.

• CI automates code testing, linting, and merging to ensure only high-quality code enters the main branch.

• CD ensures that the latest version of the app can be reliably and repeatably deployed to production servers.

Tools like GitHub Actions, Jenkins, GitLab CI, and CircleCI help automate the full pipeline—from code commit to deployment—reducing human error and accelerating release cycles.

📌 Bonus: You can also add blue/green deployments or canary rollouts to minimize deployment risk.

2 - Client Requests and DNS Resolution

Everything starts with a user in a web browser entering a domain like example.com.

• The browser performs DNS resolution to find the IP address of your app server.

• Once resolved, the request travels over the internet to your server infrastructure.

This initial handshake is critical—it’s where performance optimizations like DNS caching and HTTP/2 can shave off precious milliseconds.

3 - Load Balancers and Reverse Proxies

When traffic hits your infrastructure, it passes through a load balancer or reverse proxy (like Nginx, HAProxy, or AWS ALB).

• These tools distribute incoming requests across multiple application servers to ensure high availability and avoid overloading any single instance.

• They also handle SSL termination, URL rewriting, and sometimes even basic caching.

In a distributed architecture, load balancing is essential for scalability and fault tolerance.

4 - Content Delivery Network (CDN)

For serving static assets (like images, CSS, JavaScript, fonts), modern apps rely on CDNs such as Cloudflare, Akamai, or AWS CloudFront.

• CDNs cache content on edge servers close to users, reducing latency and load on your origin servers.

• They also add security layers like DDoS protection, WAFs (Web Application Firewalls), and TLS encryption.

Your app feels faster, especially for users across different geographies.

5 - API Layer for Business Logic

Modern web applications are often split between frontend and backend. The frontend communicates with the backend through RESTful or GraphQL APIs.

• These APIs handle authentication, business logic, user data, and session management.

• They act as the interface between the web app and core backend services, often sitting behind versioning, rate limits, and authentication layers like OAuth or JWT.

A well-structured API layer makes your app modular and scalable.

6 - Databases and Distributed Caches

To serve dynamic content, your application needs to fetch and store data efficiently.

• Databases (like PostgreSQL, MySQL, or MongoDB) store persistent data.

• Distributed caches (like Redis or Memcached) hold frequently accessed data in memory for rapid retrieval.

Using caching for session storage, search results, or product listings can reduce database pressure and improve user experience.

7 - Job Queues and Background Workers

Some tasks don’t need to happen during the user’s request-response cycle. These include:

• Sending emails

• Generating reports

• Processing images

• Syncing data with external APIs

Instead of delaying the user, these tasks are pushed to a job queue (like RabbitMQ, Sidekiq, Celery, or Bull) and picked up by background workers for processing.

This keeps your app fast and responsive while handling heavy lifting asynchronously.

8 - Search Services

If your application supports search—like product search in e-commerce or user-generated content—you’ll need full-text search engines such as Elasticsearch or Apache Solr.

• These services index your data in real-time.

• They support fuzzy search, autocomplete, faceted search, and ranking.

A dedicated search service provides richer search experiences and better performance than SQL LIKE queries.

9 - Monitoring and Observability

When your app is live, you need to know what’s happening under the hood—from response times to error rates.

Monitoring tools like:

• Grafana (dashboards)

• Prometheus (metrics collection)

• Sentry (error reporting)

• Datadog or New Relic (APM)

...provide real-time insights into your app’s health, usage patterns, and performance bottlenecks.

Good observability helps you catch issues early before they affect users.

10 - Alerting and Incident Management

When something does go wrong, the right people need to know immediately.

• Alerting tools like PagerDuty, Opsgenie, or Slack integrations send notifications based on thresholds (e.g., CPU > 90%, 5xx errors > 5%).

• Developers or DevOps teams are alerted automatically and can start resolution quickly.

Fast alerts = faster response = reduced downtime.

So, what else will you add to the list?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

Here are five key considerations every developer should keep in mind when designing APIs.

1 - The Interface

At its core, an API is an interface between systems—a contract that defines how a client can interact with a service. This involves defining:

• Resources: What are the core entities (e.g., users, products, orders)?

• Endpoints: How can clients interact with those resources? (GET /users, POST /orders, etc.)

• Request and Response Formats: Are you using JSON or XML? Are you following consistent naming conventions and data structures?

A good interface:

• Follows clear naming conventions (nouns for resources, verbs for actions).

• Uses predictable URI structures (e.g., /users/123/orders).

• Provides useful and consistent HTTP status codes (e.g., 200 OK, 201 Created, 404 Not Found).

📌 Tip: Treat your API as a product. Even if internal, others will consume it, making their experience intuitive.

2 - API Paradigms

There’s no one-size-fits-all API style. The best choice depends on the use case, performance needs, and client flexibility.

Here are the most common paradigms:

• REST (Representational State Transfer): Resource-based, stateless, widely used. Ideal for CRUD operations and simplicity.

• GraphQL: Flexible query-based paradigm where clients define the shape of the response. Great for reducing over-fetching or under-fetching of data.

• gRPC: High-performance, binary-based RPC protocol developed by Google. Ideal for internal service-to-service communication, especially in high-throughput systems.

Each has trade-offs:

• REST is easy to understand and cacheable.

• GraphQL is client-flexible but complex to secure.

• gRPC is blazing fast but not browser-native.

Choose the paradigm that best aligns with your goals—don’t force everything into REST just because it’s common.

3 - Modeling Relationships

In most real-world systems, entities don’t exist in isolation. A user has multiple orders, a blog post has comments, a product has reviews.

Your API should make these relationships clear and accessible.

Example:

Instead of:

GET /orders?userId=123

Prefer:

GET /users/123/orders

This conveys the hierarchy and makes the relationship between resources explicit. It also improves discoverability and maintains semantic clarity in your endpoints.

For GraphQL, relationships are naturally expressed in the schema and resolved on demand:

{
  user(id: "123") {
    name
    orders {
      id
      amount
    }
  }
}

Maintaining a clear, logical structure in how your API presents relationships improves both usability and maintainability.

4 - Versioning

APIs evolve. New features are added, bugs are fixed, data models change. But existing clients may still rely on older behaviors. That’s why versioning is essential.

There are a few common strategies:

• URI versioning: /v1/users, /v2/users

• Header versioning: Accept: application/vnd.myapi.v2+json

• Query param versioning: /users?version=2

The goal is to:

• Avoid breaking existing clients.

• Communicate clearly that a change has occurred.

• Allow parallel support for legacy and modern clients.

📌 Tip: Only bump a version when there’s a breaking change. Try to evolve APIs additively where possible.

5 - Rate Limiting

Without rate limiting, a single client could overload your system with thousands of requests per second, whether by accident or maliciously.

Rate limiting controls how many requests a client can make in a given time window (e.g., 100 requests per minute). This protects your backend and ensures fair usage across consumers.

Common techniques:

• Fixed window: Simple count per time bucket.

• Sliding window: Smoother traffic shaping.

• Token bucket: Allows occasional bursts within a defined limit.

Rate limits are often communicated using headers:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 20
X-RateLimit-Reset: 1650000000

You can apply different limits based on:

• API key or access token

• User role (e.g., free vs. paid)

• Endpoint type (e.g., heavy vs. light operations)

📌 Pro Tip: Always document your rate limits and include them in your API responses.

👉 So, which other key considerations do you keep while designing APIs?

Leave a comment

Shoutout

Here are some interesting articles I’ve read recently:

• The 10 Software Engineering Acronyms You MUST Know by Fran Soto

• Every Outbox Needs an Inbox by Raul Junco

• How A Single ZIP File Saved My Server From 1000s of Attacks (Code Inside) by Alexandre Zajac

• Hashing in Coding Interviews by Franco Fernando

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

That’s why smart teams follow specific transition patterns. These patterns help reduce risk, maintain stability, and allow the system to evolve gradually rather than completely rebuild.

Here are 4 such patterns that can help you:

1 - Strangler Fig Pattern

The Strangler Fig Pattern is perhaps the most famous strategy for modernizing monolithic systems. It’s inspired by how a strangler fig tree grows around an existing tree, eventually replacing it.

How It Works:

• An API gateway or proxy is placed in front of the monolith.

• New features or refactored versions of existing features are developed as independent microservices.

• The gateway routes requests:

  • To the monolith for old functionality.

  • To the new microservices for updated functionality.

• Over time, as more functionality is moved out, the monolith shrinks until it can be retired.

Why It’s Powerful:

• Incremental migration with minimal disruption.

• Reduces the big-bang rewrite risk.

• You can prioritize extracting high-value or high-risk components first.

Real-world use: Many enterprises use this approach when dealing with legacy systems where complete rewrites would be risky and expensive.

2 - Parallel Run Pattern

The Parallel Run Pattern involves running the old monolith and new microservices together for a period of time. Instead of replacing immediately, you redirect a portion of traffic to microservices to validate their behavior.

How It Works:

• Both the monolith and the new microservices are deployed simultaneously.

• Certain user requests or workflows are mirrored or split-routed:

  • Some go to the monolith.

  • Some go to the microservices.

• The output or behavior is compared to ensure that the new system is functionally equivalent.

Why It’s Useful:

• Catch errors early before full migration.

• Allows thorough real-world testing.

• You can gradually increase traffic to the microservices as confidence builds.

Pro Tip: Use feature flags and automated comparison testing to make this process smoother.

3 - The Collaborator Pattern

The Collaborator Pattern is a clever way to augment the monolith without touching its core logic immediately. It allows you to extend the system by attaching microservices around it.

How It Works:

• Instead of replacing a functionality inside the monolith, you decorate or wrap existing modules with microservices that add new features.

• The monolith still handles the original core behavior.

• Microservices add enhanced behavior, enrich responses, or intercept and modify calls.

Why It’s Valuable:

• Minimal disruption to the monolith.

• Let’s you introduce new functionality faster without waiting for core refactoring.

• Helps test microservice integration with live traffic early.

Example: Suppose you have a monolith that processes orders, but you want to add a new discount service. Instead of modifying the order logic, you add a microservice that “decorates” order responses with discount information.

4 - Change Data Capture (CDC)

One of the biggest challenges during a transition is data synchronization. Change Data Capture (CDC) provides a solution by streaming real-time database changes from the monolith to the new microservices.

How It Works:

• Tools like Debezium, Kafka Connect, or AWS DMS monitor the monolith’s database transaction logs.

• Whenever a change happens (insert, update, delete), the change is captured and streamed to interested microservices.

• This allows microservices to react in near real-time without needing tight coupling to the monolith’s database.

Why It’s Critical:

• Enables event-driven architectures during the transition.

• Allows microservices to maintain their own data stores based on monolith changes.

• Reduces reliance on synchronous API calls to the monolith.

Important Tip: Be cautious about schema evolution; changes to the monolith database schema must be carefully coordinated with CDC consumers.

How These Patterns Work Together

Transitioning from a monolith isn’t about choosing just one pattern—it’s about orchestrating them together:

• Start with the Strangler Fig to route traffic intelligently.

• Run critical paths in parallel to build trust in the new system.

• Decorate existing functionalities to add features without destabilizing the core.

• Stream changes using CDC to gradually separate data ownership.

So - have you used any of these patterns?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

Locks help prevent conflicting updates that can lead to issues like lost updates, dirty reads, or phantom reads. However, not all locking strategies are created equal. Two of the most common approaches—Pessimistic Locking and Optimistic Locking—offer different trade-offs between safety and performance.

Let’s dive into what these strategies are, how they differ, and when you should use one over the other.

What Is Pessimistic Locking?

Pessimistic locking takes a “better safe than sorry” approach. It assumes that conflicts are likely to happen, so it locks the data preemptively before any updates are made.

How It Works:

When a user or process wants to read and update a piece of data:

1. It acquires a lock on the data.

2. Other users/processes are blocked from accessing or modifying that data until the lock is released.

3. Once the operation is complete, the lock is released.

This strategy is often enforced at the database level, using exclusive locks (e.g., SELECT ... FOR UPDATE in SQL).

Advantages:

✅ Guarantees data integrity—conflicts are prevented before they can happen.

✅ Ideal for critical updates, such as financial transactions or inventory management.

Disadvantages:

❌ Reduces concurrency—other users may be blocked, even if they want to read the data.

❌ Can lead to deadlocks if multiple processes wait on each other’s locks.

❌ Affects system performance under high contention.

Best Used For:

• Systems with high contention on the same data.

• Workloads that require strong consistency, like banking or booking systems.

What Is Optimistic Locking?

Optimistic locking takes a “conflicts are rare” approach. Instead of locking data up front, it allows multiple users to access and even modify the same data concurrently, and checks for conflicts only at commit time.

How It Works:

1. When data is read, its version number or timestamp is recorded.

2. The user modifies the data without acquiring a lock.

3. When trying to write the update back:

   • The system checks whether the version number or timestamp has changed since it was read.

   • If unchanged → update is applied.

   • If changed → conflict is detected → operation is aborted or retried.

This is commonly implemented in application code or supported by ORM frameworks like Hibernate, Entity Framework, etc.

Advantages:

✅ Allows high concurrency and throughput, as there are no locks during read and modify phases.

✅ Avoids blocking and deadlock scenarios.

✅ Ideal for read-heavy applications with low conflict rates.

Disadvantages:

❌ Requires retry logic for failed transactions.

❌ May lead to wasted computation if conflicts are detected late.

❌ Not suitable for high-conflict scenarios.

Best Used For:

• Applications with many reads and few writes (e.g., social media feeds, reporting dashboards).

• Distributed systems where locking is expensive or impractical.

Best Practices for Using Locking Mechanisms

Whether you’re using pessimistic or optimistic locking, here are some tips to ensure your locking strategy works effectively:

1. Hold Locks for the Minimum Time Possible

   • Long-held locks reduce concurrency and increase the risk of contention or deadlocks.

2. Use Fine-Grained Locking

   • Lock only what’s necessary. For example, prefer row-level locks over table-level locks to reduce lock scope.

3. Implement Retry Logic (for Optimistic Locking)

   • Always anticipate that a commit may fail and prepare to retry the operation with the latest data.

4. Monitor and Tune Locking Behavior

   • Use database tools and logs to detect high lock wait times or deadlocks.

5. Choose Based on Your Data Patterns

   • If users are frequently updating the same records, pessimistic locking may be safer.

   • If updates are rare or distributed, optimistic locking will give you better performance.

So - which locking strategy have you used the most?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

In this article, we’ll dive into five popular deployment strategies.

1 - Blue/Green Deployment

Blue/Green deployment is a zero-downtime strategy that uses two identical environments: Blue (live) and Green (staging/next).

How It Works:

• The Blue environment runs the current production version.

• The new version is deployed to the Green environment, which is isolated from users.

• After thorough testing, traffic is redirected from Blue to Green via the load balancer or DNS change.

• If a problem is discovered, traffic can quickly be switched back to Blue.

Pros:

✅ Enables instant rollback.

✅ Ensures a seamless user experience with no downtime.

✅ Both environments can be tested independently.

Cons:

❌ Requires double the infrastructure, which increases cost.

❌ Managing two environments adds operational complexity.

Best For:

• Applications requiring zero downtime (e.g., fintech, healthcare).

• Mission-critical production environments.

2 - Canary Deployment

Inspired by canary birds in coal mines, canary deployment rolls out new changes to a small subset of users first, allowing you to monitor and validate the new version before a full-scale rollout.

How It Works:

• Deploy the new version to a small group (e.g., 1-5% of users or traffic).

• Monitor for errors, latency, performance, and user behavior.

• Gradually increase exposure—10%, 25%, 50%, until 100%.

• If something goes wrong, roll back quickly before most users are affected.

Pros:

✅ Helps catch issues early with minimal user impact.

✅ Enables progressive delivery.

✅ Reduces blast radius of failure.

Cons:

❌ Requires careful monitoring and alerting.

❌ Slightly more complex to automate and test.

❌ Choosing a representative canary group is crucial and non-trivial.

Best For:

• Large-scale applications where instant full rollouts are risky.

• SaaS platforms needing real-world validation before going live.

3 - A/B Testing

While not strictly a deployment strategy, A/B testing can be used as part of your release process when you want to compare different variations of a feature and measure which one performs better.

How It Works:

• Two or more variations (A, B, …) of a feature are deployed.

• Users are split into random test groups, each interacting with a different version.

• User engagement metrics like click-through rate, conversion, retention are tracked.

• The winner is chosen based on data, and the best version becomes the default.

Pros:

✅ Allows data-driven decisions.

✅ Great for validating UX, UI, or feature effectiveness.

✅ Works well with analytics tools and experimentation platforms.

Cons:

❌ Needs large user base to draw statistically significant conclusions.

❌ Can lead to technical debt if multiple experiments run in parallel without clean-up.

❌ Managing state and consistency between versions can be tricky.

Best For:

• B2C products focusing on user behavior optimization.

• Experiment-driven product teams.

4 - Feature Flag Deployment

Feature flags (also known as feature toggles) are a powerful way to deploy code without activating it immediately. Think of them as remote-controlled switches for turning features on or off.

How It Works:

• New features are deployed behind a feature flag, which controls whether the code is active or hidden.

• Flags can be toggled for specific users, teams, or environments.

• They can be used in combination with Canary, A/B testing, or staged rollouts.

Pros:

✅ Allows safe deployment with delayed exposure.

✅ Enables continuous integration and faster releases.

✅ Supports experimentation and rollback without redeploying.

Cons:

❌ Managing many flags can be complex—especially across teams.

❌ Risk of stale flags if not removed post-release.

❌ Requires discipline and tools to manage flag lifecycle (e.g., LaunchDarkly, Unleash).

Best For:

• Teams practicing continuous delivery.

• Environments where experiments and granular rollouts are common.

5 - Rolling Deployment

A Rolling Deployment replaces old application versions with new ones incrementally, usually one server or pod at a time. It’s commonly used in Kubernetes, AWS ECS, or traditional VM-based deployments.

How It Works:

• The load balancer directs traffic only to healthy instances.

• A subset of instances is taken offline and updated.

• Once healthy, traffic resumes, and the next batch is updated.

• The process continues until all instances are updated.

Pros:

✅ Reduces downtime during updates.

✅ No need for duplicate environments like Blue/Green.

✅ Well-suited for containerized and microservice environments.

Cons:

❌ May cause temporary inconsistencies (e.g., different versions running simultaneously).

❌ Rollback is harder than with Blue/Green, especially mid-deployment.

❌ Can lead to incompatible states if changes aren’t backward compatible.

Best For:

• Applications where zero downtime is needed, but budget or simplicity rules out Blue/Green.

• Kubernetes-native deployments.

Choosing the Right Strategy

There’s no one-size-fits-all deployment strategy. Your choice depends on:

• Downtime tolerance

• User base size and segmentation

• Infrastructure complexity

• Cost constraints

• Need for experimentation and analytics

👉 So - which deployment strategies have you used?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

Terraform is one tool that makes this task easy.

Whether you’re setting up a single virtual machine or orchestrating hundreds of microservices, Terraform helps you scale infrastructure efficiently and reliably.

Here’s a quick introduction to how it works. The diagram below shows the complete flow:

Stage 1: Write Infrastructure as Code

At the heart of Terraform is the concept of Infrastructure as Code (IaC). Instead of provisioning resources manually through cloud dashboards or CLI tools, you describe your infrastructure in .tf files using the HashiCorp Configuration Language (HCL).

Key Elements:

• Resources: Define infrastructure components like EC2 instances, S3 buckets, load balancers, or Kubernetes clusters.

• Providers: Define which platform you are provisioning resources in—AWS, Azure, GCP, etc.

• Variables: Allow parameterization of your code to support reusability and flexibility.

• Modules: Group common resource configurations into reusable building blocks. Modules can be custom-built or pulled from the Terraform Registry, which hosts hundreds of community-verified modules.

See the below example of a terraform configuration

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = "t2.micro"
}

This simple example defines a web server in AWS, using a variable for the AMI ID.

In larger projects, you can organize your infrastructure into multiple environments (dev, staging, prod) using modules and workspaces.

Stage 2: Terraform Plan – Preview Before Execution

After writing your configuration, you need to understand what changes Terraform will make. That’s where terraform plan comes in.

How It Works:

• Terraform reads your current state from a state file (we’ll come back to this later).

• It compares the desired state defined in your .tf files with the actual state of resources.

• It then generates an execution plan, showing what resources will be created, updated, or destroyed.

This gives you a safe, auditable preview of what Terraform intends to do—no surprises.

Why It Matters:

• Prevents unintended changes.

• Can be automated in CI/CD pipelines to enforce consistency across environments.

• Detects drift between actual and declared infrastructure state.

In a collaborative workflow, running terraform plan in a pull request helps your team review proposed infrastructure changes just like they would with application code.

Stage 3: Terraform Apply – Provision Infrastructure

Once the plan is approved, it’s time to apply the changes using terraform apply.

What Happens During Apply:

• Terraform uses the execution plan to make API calls to the appropriate cloud provider(s).

• It provisions, updates, or destroys infrastructure as needed.

• As each action completes, Terraform updates the state file to reflect the new current state of the infrastructure.

Terraform is idempotent, meaning you can apply the same configuration multiple times and it won’t duplicate resources. It only changes what’s necessary.

Providers Supported:

Terraform supports dozens of providers, including:

• Cloud platforms: AWS, GCP, Azure, Oracle Cloud

• Containers and orchestration: Kubernetes, Docker

• Monitoring: Datadog, New Relic

• Databases: PostgreSQL, MySQL

• Others: GitHub, Vault, Consul

This wide support makes Terraform ideal for managing entire ecosystems in a unified way.

Stage 4: Infrastructure Ready – The Role of State

Once resources are provisioned, Terraform maintains a state file (usually terraform.tfstate) that acts as the single source of truth for the deployed infrastructure.

Why State Matters:

• Tracks the current configuration and status of all resources.

• Enables Terraform to understand what changes need to happen in future runs.

• Allows collaboration across teams using remote backends like Terraform Cloud, S3 with DynamoDB, or Azure Storage.

For teams, storing state remotely with locking mechanisms ensures that only one person (or pipeline) modifies infrastructure at a time—preventing race conditions and accidental overwrites.

Scaling with Terraform

Terraform scales easily from a single developer managing a test environment to enterprise teams managing hundreds of services across regions. Here’s how:

• Modular design: You can create reusable modules and compose them into larger systems.

• Automated pipelines: Easily integrated into CI/CD for consistent deployment.

• Multi-cloud capability: Manage AWS, GCP, and Azure from a single configuration base.

• Drift detection and rollback: Stay in sync with real-world infrastructure.

👉 So - have you used Terraform?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

However, cache memory is limited, and when it reaches capacity, some data must be removed to make space for new entries.

This process is known as cache eviction.

Choosing the right cache eviction strategy can significantly impact performance, memory efficiency, and hit rates. Let’s look at the most popular strategies.

1 - Time-to-Live (TTL)

How TTL Works

• Each cached item is assigned a fixed expiration time.

• Once the time period expires, the item is automatically removed, regardless of how frequently it is accessed.

Best Use Cases

• Session Management: User login sessions can expire after a set time.

• Cache Invalidation for APIs: TTL ensures data freshness by automatically removing outdated responses.

• DNS Caching: DNS records use TTL to update host-to-IP mappings periodically.

Pros

✔ Simple to implement—no need to track access frequency.

✔ Ensures automatic cache refresh for time-sensitive data.

Cons

✖ Premature eviction—Frequently accessed data may expire before it’s needed again.

✖ Wasted memory—Unused data stays in cache until TTL expires, even if it’s never accessed.

Example

# Setting TTL in Redis (Item expires in 30 seconds)
SET user:123 "John Doe"
EXPIRE user:123 30

In Redis, the EXPIRE command ensures the key is removed after 30 seconds.

2 - Least-Recently Used (LRU)

How LRU Works

• When the cache is full, the least recently accessed item is evicted first.

• LRU assumes that recently accessed data is more likely to be accessed again soon (temporal locality).

Best Use Cases

• Web Browsers: Frequently visited web pages remain cached.

• Database Query Caching: Frequently executed queries are kept in cache.

• Operating Systems: Virtual memory paging systems use LRU to manage RAM efficiently.

Pros

✔ Effective for workloads with temporal locality—recently used data remains available.

✔ Self-adjusting—Adapts dynamically to access patterns.

Cons

✖ High overhead—Requires maintaining a linked list or hash map to track usage order.

✖ Not ideal for cyclic workloads—Items accessed at regular intervals may get evicted.

3 - Least Frequently Used (LFU) – Prioritizing Popular Items

How LFU Works

• Each cached item is associated with a frequency counter.

• When the cache is full, the least frequently accessed item is removed.

Best Use Cases

• Content Delivery Networks (CDNs): Frequently accessed content remains cached.

• E-commerce Product Listings: Popular products are cached for quick retrieval.

• Machine Learning Caches: Keeps frequently used datasets in memory.

Pros

✔ Better long-term cache hit rates than LRU in stable workloads.

✔ Ensures popular items remain available, even if they haven’t been accessed recently.

Cons

✖ More complex to implement—requires additional metadata to track usage frequency.

✖ Cold Start Issue—Newly added items start with a low count, leading to premature eviction.

4 - Most Recently Used (MRU) – Evicting Fresh Data First

How MRU Works

• The most recently accessed item is evicted first.

• MRU assumes that new data is less likely to be needed again soon.

Best Use Cases

• Streaming Services: The last-played song or video might not be needed again soon.

• Batch Processing Systems: Keeps older results in memory, discarding the newest.

• Database Caching for Bulk Queries: Avoids keeping temporary recent queries in cache.

Pros

✔ Works well for workloads with minimal temporal locality.

✔ Efficient when older data is more valuable than recently accessed data.

Cons

✖ Counterintuitive behavior—recently accessed items get removed first.

✖ Less effective for general caching scenarios compared to LRU.

Example

• A video player cache may use MRU to evict the last-played video first, ensuring older unwatched videos stay cached.

5 - Segmented LRU (SLRU) – A Hybrid Approach

How SLRU Works

• The cache is split into two sections:

  1. Probationary Segment: Stores newly added items.

  2. Protected Segment: Stores frequently accessed items.

• Items promoted from probationary → protected remain cached longer.

Best Use Cases

• Database Caching: Ensures frequently used queries are prioritized.

• Hybrid Cache for Dynamic Workloads: Adapts better than pure LRU or LFU.

• Large-Scale Distributed Caches: Used in Memcached and Redis for efficient cache management.

Pros

✔ Balances LRU and LFU benefits.

✔ Minimizes frequent eviction of useful data.

Cons

✖ Requires tuning of segment sizes for optimal performance.

✖ Higher memory overhead than simple LRU/LFU.

So - will you add any other strategy as well?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

But with increased complexity comes greater risk.

If you are building distributed systems, you must invest in proactive strategies to ensure resiliency. These strategies can be divided into two categories:

• Downstream Patterns

• Upstream Patterns

Let’s look at both.

Downstream Resiliency Patterns

Downstream patterns are used by the service caller. They are implemented by a service when it communicates with another service, ensuring that a failure in the downstream system doesn’t cause a domino effect.

1 - Timeouts

A timeout is a mechanism that prevents a service from waiting indefinitely for a response from a downstream service. By setting a maximum wait time, you avoid tying up resources that could be used for other requests.

Why It’s Important:

• Prevents resource exhaustion caused by requests stuck waiting indefinitely.

• Improves overall system responsiveness by allowing failed requests to be handled quickly.

Implementation Tips:

• Fine-tune timeouts based on the expected response times of downstream services. For example, a cache lookup might have a 50ms timeout, while a database query might have a 500ms timeout.

• Combine timeouts with monitoring to identify latency patterns and adjust as needed.

2 - Circuit Breaker

A circuit breaker monitors the success and failure rates of requests and temporarily disables calls to a service if failures exceed a predefined threshold. Like an electrical circuit breaker, it prevents further damage by “tripping” the connection.

Why It’s Important:

• Protects your system from overwhelming downstream services during failures.

• Allows time for the downstream service to recover.

Implementation Tips:

• Implement with standard libraries like Resilience4j to handle circuit breakers.

• Define three states for the circuit:

  1. Closed: Requests flow as usual.

  2. Open: Requests are blocked after reaching a failure threshold.

  3. Half-Open: A limited number of test requests are sent to check if the downstream service has recovered.

• Tune thresholds carefully, such as the number of failures or the time window for evaluating failures.

3 - Retries with Exponential Backoff

Retries are essential when transient failures occur.

Exponential backoff adds a delay between retries, doubling the wait time after each attempt. This gives the downstream service more time to recover and avoids overwhelming it.

Why It’s Important:

• Increases the likelihood of success when the failure is temporary.

• Reduces the risk of overloading a struggling downstream service.

Implementation Tips:

• Combine retries with a maximum retry limit to avoid infinite loops.

• Use jitter (randomized delay) in conjunction with exponential backoff to prevent synchronized retries from multiple clients causing a “thundering herd” problem.

• Example: First retry after 100ms, second after 200ms, third after 400ms, with a maximum of 5 retries.

Upstream Resiliency Patterns

Upstream patterns are used by the service owner. They are implemented by service owners to safeguard the health of their service and ensure stability during high traffic or failures.

1 - Load Shedding

Load shedding involves rejecting a portion of incoming requests when a service is overloaded.

Why It’s Important:

• Prevents complete system failure during peak loads.

• Ensures critical users or requests are prioritized.

Implementation Tips:

• Use techniques like token-bucket or leaky-bucket algorithms to control the rate of incoming requests.

• Implement priority queues to ensure critical requests (e.g., payment transactions) are handled first.

• Gradually degrade non-critical features or services under heavy load (e.g., disabling analytics during peak demand).

2 - Rate Limiting

Rate limiting sets the maximum number of requests that a client can make within a specific time window. This prevents individual clients or malicious actors from overwhelming your service.

Why It’s Important:

• Protects the service from abuse, such as Distributed Denial of Service (DDoS) attacks.

• Ensures fair resource usage across all clients.

Implementation Tips:

• Implement rate-limiting algorithms like the fixed window, sliding window, or token bucket.

• Use APIs or middleware solutions such as API Gateway, NGINX, or tools like Kong.

• Provide informative error messages (e.g., HTTP 429 Too Many Requests) to guide clients on retry strategies.

3 - Bulkheads

Bulkheading involves isolating different parts of the system to prevent failures in one component from cascading to others. This is analogous to compartments in a ship—if one is breached, the others remain unaffected.

Why It’s Important:

• Limits the blast radius of failures.

• Improves fault isolation and prevents a single failure from affecting the entire system.

Implementation Tips:

• Separate resource pools for different components (e.g., thread pools or connection pools for different services).

• Isolate critical resources to prevent non-critical services from consuming them (e.g., separate database connections for high-priority and low-priority queries).

• Use container orchestration tools like Kubernetes to allocate dedicated resources to specific services.

4 - Health Checks with Load Balancers

Health checks monitor the status of service instances and enable a load balancer to redirect traffic away from unhealthy instances. This ensures that users are always routed to functioning parts of the system.

Why It’s Important:

• Prevents traffic from being sent to failing or degraded instances.

• Improves overall user experience by minimizing downtime.

Implementation Tips:

• Use active health checks (periodic pings) or passive health checks (monitoring error rates).

• Configure thresholds for health checks, such as the number of failed requests or response latency.

• Implement rolling updates with health checks to ensure smooth deployment without downtime.

So - which resiliency patterns have you used in your project?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

In software development, the term BFF, which stands for Backends-for-Frontends, refers to a design pattern where dedicated API gateways are created for each device or interface type.

For example, you create a separate BFF for web browsers, mobile apps, or public/partner APIs.

Each BFF acts as a specialized layer between the client and the underlying services, tailoring the API to the specific needs of the client.

Key Characteristics of BFFs

1. Dedicated API Gateway: Each BFF serves as a dedicated API gateway for a specific device or interface type. It encapsulates the logic and requirements specific to that client type.

2. Customized Functionality: BFFs can handle various functionalities beyond simple API routing. They can perform tasks such as:

   1. rate limiting,

   2. authentication,

   3. header sanitization

   4. cache control

3. Decoupling from Lower-Level Services: By implementing BFFs, the logic specific to different client types is abstracted away from the lower-level services. This allows the services to focus on their core functionality while the BFFs handle client-specific requirements.

Advantages of the BFF Pattern

Implementing the BFF pattern offers several advantages:

1. Resiliency: By having separate BFFs for different client types, the impact of a faulty deployment or issue in one BFF is isolated to that specific client. Other clients remain unaffected, improving overall system resiliency.

2. Autonomy: Each BFF can be optimized according to the specific needs of the client it serves. For example, mobile clients may prefer larger responses to minimize network calls, while web clients may prioritize smaller payloads. BFFs provide the flexibility to cater to these varying requirements.

3. Development Speed: The resiliency and autonomy provided by BFFs boost developer confidence and enable faster development velocity. Teams can work independently on different BFFs without the fear of impacting other clients.

Disadvantages of the BFF Pattern

While the BFF pattern offers benefits, it also has some drawbacks to consider:

1. Code Duplication: When multiple BFFs share common functionalities, such as authorization or business logic, there is a risk of code duplication across the BFFs. This can lead to maintenance challenges and inconsistencies.

2. Complexity: As the BFFs become responsible for more glue-logic and orchestration of services, they can become more complex over time. Managing this complexity requires careful design and maintenance.

3. Proliferation of BFFs: Developers may be tempted to create a new BFF for every slightly different scenario, leading to an excessive number of BFFs. This can result in increased complexity and maintenance overhead.

Best Practices for Implementing BFFs

To effectively leverage the BFF pattern, consider the following best practices:

1. Clearly Define Client Requirements: Thoroughly understand the specific requirements of each client type and design the BFFs accordingly. Avoid creating unnecessary BFFs for minor variations.

2. Minimize Code Duplication: Identify common functionalities across BFFs and consider extracting them into shared libraries or services to minimize code duplication.

3. Maintain Clear Boundaries: Clearly define the responsibilities of each BFF and ensure they align with the overall system architecture. Avoid overloading BFFs with excessive functionality.

4. Monitor and Optimize Performance: Regularly monitor the performance of BFFs and optimize them based on client requirements and usage patterns. Ensure efficient resource utilization and scalability.

So - have you used the BFF pattern?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

See you later with another edition — Saurabh

I’m talking about the TCP 3-way handshake.

Every time you open a website, TCP makes sure this handshake happens and you get a reliable connection.

How does TCP pull it off?

Let’s look at each step:

1 - SYN (Synchronize)

• Think of it as one party extending their hand for a handshake.

• The process starts with the client sending a TCP segment to the server with the SYN flag set.

• Also, the client selects an initial sequence number (ISN) and includes it in the SYN segment. Let’s say the ISN is 1000.

• This tells the server that the client wants to establish a connection.

2 - SYN-ACK (Synchronize Acknowledge)

• This is like the second party taking the hand.

• The server receives the SYN segment and responds by sending a SYN-ACK segment to the client.

• Before sending, the server sets the SYN flag and the ACK flag in the segment

• The ACK flag is meant to acknowledge the receipt of the client’s SYN segment by incrementing the ISN by 1 (i.e. 1001)

• The server also selects its own ISN (let’s say 5000) and includes it in the SYN-ACK segment.

3 - ACK (Acknowledge)

• This is where the two parties shake hands.

• The client receives the SYN-ACK segment.

• The client acknowledges the server’s response by sending another TCP segment with the ACK flag set.

• The sequence number in the segment is set to the server’s ISN incremented by 1 (basically, 5001)

After this, the connection is established.

The diagram below shows all the three steps:

FAQs

A few additional FAQs about the entire TCP handshake business:

What’s the deal with SYN and ACK? What are these exactly?

In TCP, several control flags are used to manage different aspects of the communication process. These flags are bits in the TCP header.

Some common ones are SYN, ACK, FIN, RST, PSH, and so on.

Why sequence numbers (ISNs) are so important?

The numbers help the client and server keep track of the message order so that nothing gets missed.

Also, these numbers are randomized and help prevent malicious actors from hijacking the TCP session.

Is the Internet moving away from TCP?

HTTP/3 doesn’t use TCP but relies on QUIC (Quick UDP Internet Connections). So yes, we may see a gradual move away from TCP.

However, the majority of websites are still on HTTP/1.1 and HTTP/2. So nothing is going to happen tomorrow.

So - what do you think about the TCP 3-way handshake?

Is it an overkill? Or a great mechanism for establishing connections?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

See you later with another edition — Saurabh

At its core, OOP is based on four fundamental principles: Abstraction, Encapsulation, Inheritance, and Polymorphism.

Let’s break down each concept with explanations, examples, and best practices.

1 - Abstraction

Abstraction is the process of hiding complex implementation details while exposing only the essential features of an object. It allows developers to work with high-level concepts without worrying about the underlying implementation.

How It Works

Imagine a Car class with a method called stop(). Users of this class don’t need to know how the car stops—they just need to call stop(), and the underlying implementation takes care of the details.

abstract class Car {
    abstract void stop();  // Abstract method, no implementation
}

class Honda extends Car {
    @Override
    void stop() {
        System.out.println("Honda slowing down and stopping.");
    }
}

class Tesla extends Car {
    @Override
    void stop() {
        System.out.println("Tesla applies brakes and stops.");
    }
}

Here, Car defines the stop() method but doesn’t provide an implementation. Honda and Tesla provide their specific implementations, hiding the details from the users of these classes.

Why Abstraction Matters

• Simplifies complex systems by exposing only necessary parts.

• Improves code maintainability by separating the interface from implementation.

• Enhances security by hiding implementation logic from unauthorized access.

2 - Encapsulation

Encapsulation is the concept of bundling data (fields) and methods that operate on the data into a single unit (class) while restricting direct access to the data.

How It Works

Encapsulation is achieved using access modifiers (private, protected, public) to control access to variables and methods.

class BankAccount {
    private double balance;  // Private variable, cannot be accessed directly

    public BankAccount(double initialBalance) {
        this.balance = initialBalance;
    }

    public void deposit(double amount) {
        if (amount > 0) {
            balance += amount;
        }
    }

    public double getBalance() {
        return balance;  // Provides controlled access to balance
    }
}

Here balance is private, so it cannot be accessed directly from outside. Also, getBalance() is public, allowing controlled access to the balance.

Why Encapsulation Matters

• Protects data integrity by preventing unauthorized modifications.

• Reduces dependencies by keeping data and its operations in one place.

• Enhances flexibility as changes to implementation don’t affect external code.

3 - Inheritance

Inheritance allows a class (child) to inherit attributes and methods from another class (parent). This promotes code reuse and hierarchical relationships between classes.

How It Works

Consider a Vehicle class. Instead of rewriting common functionality for each type of vehicle, a Car and Bike can inherit from Vehicle.

class Car {
    String brand = "Generic Brand";

    void honk() {
        System.out.println("Beep! Beep!");
    }
}

class Car extends Vehicle {
    int doors = 4;
}

public class Main {
    public static void main(String[] args) {
        Car myCar = new Car();
        System.out.println(myCar.brand);  // Inherited from Vehicle
        myCar.honk();  // Inherited method
        System.out.println("Number of doors: " + myCar.doors);
    }
}

Here, Car inherits brand and honk() from Vehicle, reusing existing logic.

Why Inheritance Matters

• Reduces code duplication, making maintenance easier.

• Creates hierarchical relationships (e.g., Animal → Mammal → Dog).

• Improves extensibility, allowing new behaviors to be added to child classes.

4 - Polymorphism

Polymorphism allows a single method to behave differently based on the object it is called on. This means one function can be applied to multiple object types.

There are two types of polymorphism:

1. Compile-time

2. Run-time

How It Works

Here’s an example of polymorphism:

class MathOperations {
    int add(int a, int b) {
        return a + b;
    }

    double add(double a, double b) {
        return a + b;
    }
}

public class Main {
    public static void main(String[] args) {
        MathOperations math = new MathOperations();
        System.out.println(math.add(5, 10));  // Calls int version
        System.out.println(math.add(5.5, 2.2));  // Calls double version
    }
}

Here, the add() method behaves differently based on the parameter type.

Why Polymorphism Matters

• Enhances flexibility by allowing objects of different types to be treated uniformly.

• Encourages code extensibility without modifying existing code.

• Supports the Open-Closed Principle (OCP)—extend behavior without modifying existing logic.

So - have you used object-oriented programming? And are there any other concepts you find important?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

It hosts billions of posts. And a lot many of these posts contain media content such as images, videos, gifs, and so on.

While the media content is often stored in object storage, the metadata needs to be stored elsewhere. For example, if you’ve got a video, you might need to store information such as the thumbnail URL, playback URLs, bitrates, and various resolutions.

Reddit had a big problem with this metadata.

While their systems had the information, it was scattered across multiple systems. Media data used for traditional image and video posts was stored with post data, whereas media data related to chats and other types of posts was stored in a different database.

This made it difficult for them to analyze and categorize the metadata. Auditing changes became tough. Even checking information about a specific image or video required them to query the S3 bucket.

To solve these challenges, the Reddit Engineering team decided to build a media metadata store.

Requirements of the Metadata Store

There were several requirements for the new metadata store:

• Move all existing media metadata from different systems into a unified storage. In other words, migrate existing data to the new database.

• Support data retrieval to the tune of over 100K read requests per second with very low latency (less than 50 ms).

• Support media creation and updates.

After evaluating multiple choices, the Reddit Engineering Team went for AWS Aurora Postgres.

The diagram below shows a high-level architecture of their media metadata storage system.

The API service interfaces with the database to handle both reads and writes. To manage the connection pooling, they use pgBouncer as the proxy for connecting to Postgres.

Just so you know, pgBouncer is a lightweight connection pooler for Postgres.

Data Migration Process

While setting up a new Postgres database is easy, the real challenge lies in migrating terabytes of data from one database to another while serving 100K requests per second.

It’s like changing a car’s tires while you are driving it.

The consequences of the new database having the wrong media metadata could spell disaster for the website.

The migration was handled as follows:

• Enable dual writes into both the new and old databases from the clients of media metadata. This ensures that any new metadata is stored in the new database.

• Backfill data from older databases to the metadata store.

• Next, enable dual reads on media metadata from our service clients.

• Compare the output of the reads and fix any data gaps.

• Ramp up read traffic to the new database.

Here’s what the dual writes and backfill part looks like.

Dealing with Issues

While the overall approach is fine from a happy path perspective, that’s not always the case in real software development.

Some issues that could come up are as follows:

• Data transformation bugs in the service layer.

• Writes to the new metadata store could fail and the writes to the source database succeed resulting in inconsistent data.

• The backfill process during migration can overwrite newer data from the service write.

To handle these scenarios, the Reddit team built a more robust solution as shown below:

Here is what’s going on:

• The client dual writes to the new database and the old database.

• A Kafka consumer listens to the stream of data change events from the source database. This is done using a Change Data Capture (CDC) process.

• The consumer performs data validation with the media metadata store to check inconsistencies.

• In case of any inconsistency, the consumer reports the differences to another database so that engineers can take a look and fix the issues.

What about Scaling?

The new media metadata store was heavily optimized for reads, helping Reddit achieve a p50 latency of 2.6 ms and p99 latency of 17 ms at 100K requests per second.

However, the data volume is also quite high and according to their estimates, the media metadata can reach 50 TB by 2030.

To handle this scalability challenge, Reddit has implemented partitioning in Postgres using an extension known as pg_partman.

The above SQL statement is scheduled using the pg_cron scheduler to create new partitions when the number of spare partitions goes below a certain number.

They used range-based partitioning instead of hash-based partitioning for the partition key post_id.

This is because range-based partitioning on a monotonically increasing field such as post_id automatically ensures the partitions are created based on distinct time periods.

Since most read requests at Reddit target recent posts, it allows the Postgres engine to cache the indexes of the most recent partitions in its buffer pool. In other words, less Disk I/O and better performance.

So - what do you think about Reddit’s solution to the metadata problem?

Would you have done something differently?

Leave a comment

References:

• The Reddit Media Metadata Store

• pgBouncer

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

See you later with another edition — Saurabh

As you might know, Agoda’s goal is to aggregate and provide the best prices from various external suppliers (hotels, restaurants, cab providers, etc). To ensure that customers always get the most up-to-date and accurate pricing information, Agoda’s supply system needs to process a massive amount of price updates from the suppliers in real time.

For example, a single supplier can provide 1.5 million price updates and offer details in just one minute. Any delays or failures in reflecting these updates can lead to incorrect pricing and booking failures.

Here’s how the typical Kafka application setup within Agoda’s supply system looks like:

The key components are as follows:

• Distributor: The component consumes price updates from various 3rd party systems (suppliers) and distributes processing jobs to the downstream processor service across multiple data centers.

• Processor: The processor service is responsible for transforming, processing, and delivering the updates to the downstream services and databases.

• Kafka: It acts as the messaging backbone between the distributor and processor components.

One of the key features of Kafka that makes it suitable for such large-scale data processing is the use of partitions.

Partitions help Kafka achieve parallelism by distributing the workload across multiple partitions and consumers. In other words, it can process messages faster and more efficiently.

However, Agoda’s online travel booking platform had some challenges that were made more apparent by Kafka’s parallelism.

Partitioner and Assignor Strategy

The partitioner and assignor strategies in Kafka play a crucial role in determining how messages (price updates from suppliers) are distributed across partitions and consumers.

• Partitioner: Determines how messages are distributed across partitions when they are produced. For example, round-robin strategy and sticky partitioning.

• Assignor: Determines how partitions are assigned to consumers within a consumer group. For example, range assigner and round robin assigner.

See the diagram below for a round-robin partitioner and round-robin assignor strategy:

Traditionally, these strategies were designed to work under the assumptions of homogenous consumer processing capabilities and uniform message workloads.

However, in Agoda’s case, these assumptions didn’t hold true leading to load-balancing challenges related to Kafka.

Challenges

The two main challenges are as follows:

• Heterogenous Hardware: Agoda uses a private cloud with Kubernetes which can lead to pods running on servers of different hardware generations. Benchmarks show significant performance differences between hardware generations.

• Uneven Workload: Messages may require different processing steps, leading to varying processing times. For example, processing certain types of messages may require calling 3rd party APIs and executing database queries, resulting in latency fluctuations.

These challenges led to the over-provisioning problem.

The Over-provisioning Problem At Agoda

Agoda initially used the Kafka round-robin partitioner and assigner to distribute the same number of messages to each partition and pod.

However, this led to over-provisioning.

Over-provisioning involves allocating more resources than necessary to handle the expected peak workload efficiently.

In Agoda’s case, the reason was an inefficient distribution of the load across their Kafka consumers.

For example, consider an example where Agoda deploys Kafka consumers on heterogeneous hardware in their processor service. Suppose they have:

• 2 faster workers with a processing rate of 20 messages/second each.

• 1 slower worker with a processing rate of 10 messages/second.

In this setup, the total expected capacity would be 20 + 20 + 10 = 50 messages/second.

However, with a round-robin distribution, each worker would receive 1/3 of the overall messages regardless of processing speed. If the incoming traffic consistently hits 50 messages/second, here’s what would happen:

• The 2 faster workers can easily handle their share of ~ 16.7 messages per second each.

• The slower worker cannot keep up with its allocated ~16.7 messages per second, causing the lag to build up over time.

The diagram below shows this scenario:

To avoid high latency, Agoda would have to add extra resources to this setup to maintain processing SLAs. In this example, to process 50 messages/second, they would need to scale out to 5 machines. In other words, they end up over-provisioning by 2 extra machines due to the suboptimal distribution logic that doesn’t account for heterogeneous hardware.

Also, the same scenario can occur when the workload for each message is not identical. Either way, it results in:

• Increased hardware costs

• Wasted resources as some consumers sit idle while others are overburdened

• More maintenance overhead

The Solution Agoda Didn’t Adopt

The first obvious solution to overcome the over-provisioning challenge was static balancing. There were mainly two approaches in this regard:

• Deployment on identical pods

• Weighted load balancing

Deployment on Identical Pods

This solution involves controlling the types of hardware used in service deployments. However, it had some drawbacks:

• Maintaining a homogeneous hardware environment can be expensive, especially in a private cloud setup.

• Upgrading all existing hardware simultaneously can be challenging.

Due to these reasons, it was not adopted.

Weighted Load Balancing

In this approach, varying weights are assigned to different consumers based on processing capacity. Consumers with higher weights are routed more traffic.

This solution works well when:

• The capacity of consumers is predictable and remains static.

• The workload of messages is uniform, making it easier to estimate machine capacity.

However, there were some challenges in implementing this in a real production environment at Agoda:

• Messages often had non-uniform workloads, making capacity estimation difficult.

• Dependencies like network and 3rd party connections were unstable, leading to fluctuating capacities.

• Frequent addition of new features required extra maintenance to keep the weights updated.

Agoda’s Dynamic Lag-Aware Solution

Instead of the static rebalancing approaches, Agoda adopted a dynamic, lag-aware approach to solve the Kafka load balancing challenges. They implemented two main strategies:

• Lag-aware Producer

• Lag-aware Consumer

Lag-aware Producer

A lag-aware producer dynamically adjusts the partitioning of messages based on the current lag information of the target topic. Here’s how it works:

• The producer maintains an internal cache of partition lags to reduce the number of calls to Kafka brokers.

• Using the lag data, the producer applies a custom algorithm to publish fewer messages to partitions with high lag and more messages to partitions with low lag.

• When lags are balanced and stable, this approach guarantees an even distribution of messages.

For example, let’s consider a scenario where Agoda’s supply system has an internal producer that publishes task messages to its processor. The system has 6 partitions with the following lags:

• Partition 1 → 100 messages

• Partition 2 → 120 messages

• Partition 3 → 90 messages

• Partition 4 → 300 messages

• Partition 5 → 110 messages

• Partition 6 → 280 messages

In this case, the lag-aware producer would publish fewer messages to partitions 4 and 6 due to their high lag while publishing more messages to the other partitions with lower lag.

The diagram below illustrates this.

Lag-aware Consumer

Lag-aware consumers are used when multiple consumer groups subscribe to the same topic. Here’s how they work:

• In a downstream service like the Processor, a consumer instance experiencing high lag can proactively unsubscribe from the topic to trigger a rebalance.

• During the rebalance, a customized Assigner redistributes the partitions across all consumer instances based on their current lag and processing capacity.

• Kafka 2.4’s incremental cooperative rebalance protocol minimizes the performance impact of rebalancing, allowing for more frequent adjustments.

For example, consider a scenario where Agoda’s Processor service has 3 consumer instances consuming from 6 partitions:

• Worker 1 → Partitions 1 and 2

• Worker 2 → Partitions 3 and 4

• Worker 3 → Partitions 5 and 6

If Worker 3 is running on slower hardware, it may experience higher lags in partitions 5 and 6. In this case, Worker 3 can proactively unsubscribe from the topic, triggering a rebalance. The custom Assigner then redistributes the partitions based on the current lag and processing capacity of each worker.

Algorithms for Lag-aware Producer

Coming back to the Lag-aware producer, Agoda used two main algorithms:

• Same-Queue Length Algorithm

• Outlier Detection Algorithm

1 - Same-Queue Length Algorithm

The Same-Queue Length Algorithm aims to achieve equal queue lengths across all partitions by adjusting the number of messages published to each partition based on the current lag.

For example, consider a scenario with 4 partitions having the following lags:

• Partition 1 → 100 messages

• Partition 2 → 150 messages

• Partition 3 → 120 messages

• Partition 4 → 200 messages

The target queue length would be 200 (the maximum lag). The algorithm would then publish messages as follows:

• Partition 1 → Publish 100 messages (200 - 100)

• Partition 2 → Publish 50 messages (200-150)

• Partition 3 → Publish 80 messages (200 - 120)

• Partition 4 → Publish 0 messages (already at the target)

See the diagram below:

2 - Outlier Detection Algorithm

The Outlier Detection Algorithm identifies partitions with abnormally high lag (outliers) and temporarily stops publishing messages to those partitions to allow them to catch up.

It uses statistical methods like Interquartile Range (IQR) or Standard Deviation (STD) to identify outlier partitions.

For example, consider a scenario with 6 partitions having the following lags:

• Partition 1 → 100 messages

• Partition 2 → 120 messages

• Partition 3 → 300 messages

Using the IQR method, partition 3 is identified as an outlier (slow partition). The algorithm would then:

• Stop publishing messages to partition 3

• Evenly distribute messages among partitions 1 and 2.

• If partition 3 improves and is no longer an outlier, gradually resume publishing messages to them.

So - what do you think about Agoda’s load-balancing solution for Kafka? Would you have done something differently?

Leave a comment

Reference:

How We Solve Load Balancing Challenges in Apache Kafka

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

See you later with another edition — Saurabh

Let’s say this is the query:

SELECT name, age FROM users WHERE city = ‘New York’;

Here’s a diagram that shows the process visually:

Let’s go through each step in more detail:

STEP 1

When you hit run, the query string first reaches the Transport Subsystem of the database.

As the name suggests, this subsystem manages the connection with the client.

It also performs initial authentication and authorization checks, and if satisfied, lets the query go to the next step.

STEP 2

The query now reaches the Query Processor, which has two main parts:

• Query Parser

• Query Optimizer

The Query Parser breaks down the SQL query into its parts (SELECT, FROM, WHERE, etc). It checks for any syntax errors and creates a parse tree.

Then, the Query Optimizer goes through the parse tree, checks for semantic errors (e.g. - if the ‘users’ table exists or not), and determines the most efficient way to execute the query.

As output, the optimizer produces an execution plan.

STEP 3

Next, the execution plan makes its way to the Execution Engine.

The plan is made up of all the steps that are needed to execute the query.

The Execution Engine takes this plan and coordinates the execution of each step by calling the Storage Engine. It also collects the results from each step and returns a unified response to the upper layer.

STEP 4

The Execution Engine sends low-level read/write requests to the Storage Engine depending on the execution plan.

All of this is facilitated by the various employees of the Storage Engine.

For example,

• The transaction manager ensures that the query runs within a transaction for consistency.

• The lock manager acquires necessary locks on the “users” table to prevent conflicts.

• The buffer manager checks if the required data pages are already in memory. If not, it requests the data to be loaded from the disk into memory.

• The recovery manager logs the operations for rollback or recovery.

👉 So - what else would you add to this journey of an SQL query?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

See you later with another edition — Saurabh

Why?

Because your database is struggling to keep up.

This is a common problem in backend development—your code executes in milliseconds, but your database queries take seconds. If you don’t address this, you’ll end up with sluggish APIs, frustrated users, and a system that crumbles under load.

Let’s explore why databases slow down and how to fix them.

Why the Database Can Become a Bottleneck?

Databases are slower than code execution.

Your application code runs in memory, but your database reads and writes data from disks or over a network. Even with SSDs and optimized database engines, disk access and network calls are still much slower than in-memory operations.

But how do you know if your database is causing performance issues?

Look for these symptoms:

• Your API requests take a long time despite minimal application logic.

• Your database CPU usage is always high.

• Queries take longer as your data grows.

• Your application struggles under high user traffic.

Diagnosing the Problem

Before you start optimizing, you need to identify the actual bottlenecks. Here’s how:

Use Query Profiling

Every major database has a way to analyze slow queries:

• MySQL & PostgreSQL: Use EXPLAIN ANALYZE to check execution plans.

• MongoDB: Use .explain() to analyze queries.

• Slow Query Logs: Identify the queries that are taking the most time.

For example:

EXPLAIN ANALYZE SELECT * FROM orders WHERE status = 'pending';

This will show how your database processes the query and where the delays are happening.

Look at Key Performance Metrics

Monitor the following database metrics:

• Query execution time: Are some queries consistently slow?

• Read/write latency: Is your database struggling with high read or write operations?

• Locking issues: Are queries blocking each other?

• Connection pooling: Are too many connections being opened and closed?

Once you’ve identified the slow queries, you can start optimizing them.

Database Locking & Deadlocks

When multiple queries or transactions run concurrently, databases use locking mechanisms to ensure data consistency.

However, poor transaction management can lead to deadlocks, where two or more queries wait indefinitely for each other to release a lock, causing performance bottlenecks.

There are different types of locks:

• Row-level locks: Lock individual rows, allowing higher concurrency. (Ideal for OLTP applications)

• Table-level locks: Lock the entire table, preventing modifications while a transaction is running. (Can cause slowdowns)

• Shared vs. Exclusive locks: Shared locks allow multiple reads, while exclusive locks block all access until completion.

Some best practices to deal with deadlocks are as follows:

• Keep transactions short and efficient (commit early).

• Access tables in a consistent order across transactions.

• Use indexing to reduce unnecessary locks.

• Monitor for deadlocks using SHOW ENGINE INNODB STATUS; (MySQL) or pg_stat_activity (PostgreSQL).

Optimizing Your Queries

Optimizing queries is a quick win. Here are some common tips that can help:

1 - Add Indexes (The Right Way!)

Indexes speed up lookups by avoiding full table scans.

For example, the query below would be considered bad without indexes in the email field.

SELECT * FROM users WHERE email = 'user@example.com';

A simple fix would be to create the index on email.

CREATE INDEX idx_email ON users(email);

With an index, the database can locate the data instantly instead of scanning every row. However, too many indexes slow down writes, so there is a trade-off involved. Make sure to only index the columns you frequently search on.

2 - Avoid SELECT *** (Be Specific)

Fetching all columns when you only need a few wastes resources. For example, the below query should not be used:

SELECT * FROM orders WHERE status = 'pending';

A better option is the query below:

SELECT id, customer_id, total_price FROM orders WHERE status = 'pending';

This reduces the amount of data transferred and speeds up queries.

3 - Use Joins & Reduce Nested Queries

Avoid nested queries. For example:

SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE city = 'New York');

Using joins like the example below can be a much better strategy.

SELECT orders.order_id 
FROM orders 
JOIN customers ON orders.customer_id = customers.id 
WHERE customers.city = 'New York';

Joins are optimized by the database, whereas nested queries can cause multiple redundant lookups.

Scaling Beyond Queries: Architectural Optimizations

Some optimizations are also required on the architectural level to improve database performance. Here are some examples:

Schema Design

Database schema design directly impacts query speed, scalability, and storage efficiency. Poor schema decisions lead to slow queries, high storage costs, and scaling bottlenecks.

Here’s how to optimize schema design for better performance:

1 - Normalization vs. Denormalization: Trade-offs

• Normalization (3NF and above) reduces data redundancy by breaking tables into smaller, related entities.

  • Pros: Saves space and avoids update anomalies.

  • Cons: Can slow down read-heavy queries due to excessive JOINs.

• Denormalization merges frequently used data to reduce JOINs, making reads faster at the cost of extra storage and potential update issues.

  • Pros: Great for analytics & high-read workloads.

  • Cons: Can lead to data inconsistency if not managed properly.

Rule of Thumb: Normalize when you expect frequent writes, denormalize when reads dominate.

2 - Choosing the Right Data Types

• Use BIGINT instead of UUID for primary keys unless uniqueness across distributed systems is needed.

• Use BOOLEAN for true/false values.

• Use TEXT/JSONB sparingly. This is because indexable columns are faster for queries.

Use Caching

Instead of hitting the database every time, store frequently accessed data in a cache (Redis, Memcached). This reduces database load significantly.

For example, cache the result of expensive queries.

cache.set("user_123_orders", query_result, expire=300) # Expires in 5 minutes

Optimize Database Connections

Opening and closing database connections is expensive. Use connection pooling to reuse existing connections instead of creating new ones for every request.

For example, use pgbouncer for PostgreSQL connection pooling.

Materialized Views for Precomputed Expensive Queries

A Materialized View is a precomputed query result stored as a physical table. Unlike a regular database view, which runs a query every time it’s accessed, a materialized view stores the result persistently, making expensive queries much faster.

For example, suppose we frequently calculate total sales per day from a huge orders table:

SELECT order_date, SUM(total_price) AS daily_sales
FROM orders
GROUP BY order_date;

If the orders table is massive, this query slows down dashboards and reports. To handle this, you can create a materialized view. This way queries can read directly from the view instead of querying the orders table.

However, materialized views don’t usually auto-update when data changes. There needs to be a mechanism to update them. Also, this approach is not suitable for real-time data needs.

Sharding & Partitioning for Large Datasets

When your database gets huge, split data across multiple servers (sharding) or distribute tables across partitions.

For example:

• Shard users based on country (users_us, users_eu)

• Partition orders by date (orders_2023, orders_2024)

This reduces the load on a single table and speeds up lookups.

Use Read Replicas for Scaling Reads

If you have millions of reads per second, create read replicas to distribute the load.

For example:

• Primary DB: Handles writes and critical reads.

• Read Replicas: Handle read queries.

Many large-scale systems use this approach for redundancy as well as improved durability.

Conclusion: Diagnose Before You Optimize

Here are some tips to keep in mind:

• Don’t blindly optimize—use logs and profiling to find real bottlenecks.

• Start with query optimization—indexes, joins, and batching solve 80% of problems.

• Use caching and read replicas—offload repetitive queries.

• Think about scaling architecture—sharding, partitioning, and hybrid databases.

A slow database doesn’t have to hold you back. With the right optimizations, you can make your system blazing fast and scalable.

👉 So - which other tip will you add to optimize the database access?

Leave a comment

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

See you later with another edition — Saurabh

This monolith was responsible for both client and server-side functionality. The model, view, and controller layers were packed into a single repository.

A simple diagram for this architecture would appear as follows:

There were several advantages to this monolithic approach:

• Easy to get started initially.

• Good for agile development

• Manageable complexity levels

Those were simpler times and such times usually don’t last. Airbnb grew fast, and its engineering team doubled and tripled. Suddenly, you had more and more developers adding new code and features to the monorail.

Just like too many cooks spoil the dish, the code base started to get tightly coupled, and data ownership became muddled. Any developer could make changes to any part of the application, making it difficult to track and coordinate the changes.

Airbnb decided to migrate from the monorail to a Service-Oriented Architecture. You could also see it as a move towards loosely coupled microservices.

The Rules of the Game

Of course, Airbnb was wise and came up with some key design principles for building services. Some of the rules are mentioned below:

• A service should own both the reads and writes to its data. This is similar to the database-per-service pattern where a particular piece of data is owned by one and only one service.

• A service should address a specific concern

• Services should avoid duplicating functionality

• Data changes should happen via standard events to encourage loose coupling.

• Each service must have proper alerting and observability settings

The SOA Design

After a few years of migration stuff, Airbnb ended up with the below architecture:

Let’s unpack it a bit.

• The bottom layer is composed of data services. These services are the entry point for all interactions with the database and aren’t dependent on any other service.

• The derived services read data from other services and apply basic business logic. They can also have specialized data storage to store any derived data.

• The middle-tier services contain the key business logic that doesn’t fit at the data service level or the derived data service level.

• At the very top are the presentation services. These services aggregate data from all other services and apply frontend-specific business logic before returning the data to the client.

The Migration

The move from the monorail to shiny new services wasn’t an overnight process. Also, migrating reads and writes had their problems.

Let’s look at both scenarios and how Airbnb handled the migration.

Migrating the Reads

Airbnb used dual reads and response comparison for the old read path (through the monorail) and the new read path (the service).

See the diagram below:

Every read request went through both paths. The responses were sent to a comparison framework. Once the engineers were sure that things were as expected, the traffic to the service path was ramped up.

Migrating the Writes

Writes were trickier because one cannot dual-write to the same database. Therefore, the engineers used a shadow database.

See the diagram below:

The new service initially writes to the shadow database. After that, read requests are sent to the prod and shadow database, and the responses are sent to the comparison framework.

Only after the comparison came out clean, the writes were completely switched to the new service.

Lessons

Airbnb had several important lessons from this whole migration process. A few important ones for us are as follows

• Invest in common infrastructure pieces early on. Things like shadow databases, comparison frameworks, etc. can help during the migration.

• Simplify the service dependencies

• Moving to services is not just technical but also a cultural change for the organization.

• The migration isn’t a fixed destination but a journey.

So - what do you think about Airbnb’s migration journey? Would you have done something differently?

Leave a comment

References:

• Airbnb’s Migration from Monolith to Services

• Airbnb at Scale

That’s it for today! ☀️

Enjoyed this issue of the newsletter?

Share with your friends and colleagues.

Share

See you later with another edition — Saurabh