One of the biggest surprises when moving into senior engineering or engineering management roles is how often you need to evaluate systems you didn’t design. You’re handed a document, a diagram, or a pitch – and you have 30 minutes to understand whether the architecture is sound, scalable, operationally manageable, and worth investing in.

The good news: you don’t need to know every detail.

Over the years, I’ve developed a fast, structured way to assess an architecture with enough confidence to ask the right questions and catch the biggest risks early. This is the same approach I use in design reviews and technical strategy discussions today.

This isn’t a checklist of tiny details.

This is how you see the shape of a system quickly.

⸻

Step 1: Understand the Core Flow (5 minutes)

Every distributed system has a “dominant path” – the sequence of actions that matter most for correctness, performance, and customer experience.

Ask the presenter or yourself:

1. What is the primary customer action?

(Upload, read, write, query, process, etc.)

1. What components does that action flow through?

Identify the small number of components that appear on every request.

1. Where are the critical boundaries?

• Cross-region?

• Cross-account?

• Cross-service?

If you understand the happy path, you’re already 60% of the way to evaluating the architecture.

Red flags: unclear data flow, inconsistent diagrams, components that seem duplicated without explanation.

⸻

Step 2: Identify the Single Points of Failure (5 minutes)

Distributed systems don’t fail in subtle ways – they fail in embarrassingly predictable ones.

Look for:

• A single database with no replication strategy

• A queue with unclear DLQ behavior

• A single compute layer without autoscaling

• A service that only runs in one zone

• A region dependency that breaks the idea of “multi-region”

Your goal here is not to fix the design but to surface the assumptions the team is making.

A healthy architecture can answer:

• What happens if this component fails?

• How does the system degrade?

• How do we recover?

If they can’t answer those, you just found your first major risk.

⸻

Step 3: Stress the System at Scale (5 minutes)

A design that works for 100 requests per second can collapse at 10,000.

Ask:

• What’s the biggest bottleneck at 10× scale?

• Which component becomes cost-prohibitive first?

• Where does backpressure show up?

• What’s the critical path for latency?

You want to know where the system bends and where it breaks.

This is where senior engineers shine – spotting the performance cliffs before they appear in production.

⸻

Step 4: Validate Operational Excellence (5 minutes)

A system isn’t “done” when it works. It’s done when it can be operated.

Look for:

• Metrics identified per component

• Alarms tied to real failure modes, not vanity metrics

• Clear runbooks for disasters

• Observability across request boundaries

• Idempotency and retry strategies

If the design doc or architecture review never mentions alerts, dashboards, retries, or logs, it isn’t production-ready.

A system that can’t be operated will eventually fail – harder than it should.

⸻

Step 5: Evaluate Data Consistency and Boundaries (5 minutes)

Every distributed system is balancing tradeoffs:

• Latency vs durability

• Freshness vs availability

• Strong consistency vs eventual consistency

• Write amplification vs throughput

• Cost vs correctness

Great designs state these tradeoffs explicitly. Mediocre designs pretend they don’t exist.

Your job is not to enforce one model – but to ensure the model chosen matches customer expectations.

Example questions:

• What happens if two writes occur at the same time?

• Do clients read their own writes?

• What’s the reconciliation strategy for conflicts?

If no one can explain the consistency model, assume the architecture has hidden correctness risks.

⸻

Step 6: Ask the “Tell Me the Story” Question (5 minutes)

My favorite closing question in any architecture review:

“Walk me through the worst day this system has.”

On a bad day:

• a dependency is throttling,

• a region is degraded,

• a batch job is stuck,

• a rollback is in progress,

• the load is higher than expected.

A mature design has a believable story here.

An immature one melts.

This question reveals:

• Real operational risks

• Organizational dependencies

• Failure cascades

• Whether the team has truly internalized the design

If they can tell a good story, the architecture is usually good.

⸻

Putting It All Together

You don’t need a full day or a deep dive to evaluate a distributed system.

You need a structured, repeatable way to uncover:

• correctness risks

• scaling bottlenecks

• availability weaknesses

• operational gaps

• unclear tradeoffs

In 30 minutes, you can surface 80% of the biggest issues – long before code is written.

If you’re a senior engineer, tech lead, or engineering manager, build this skill. It becomes one of the most valuable tools you have.

For more than a decade, this blog has been a place where I explored deep technical problems – distributed systems quirks, backend architecture challenges, and the kind of engineering details that only show up when you’ve been building things long enough to know where they break.

Over the past few years, my work has changed. Today, as a Senior Manager at AWS, I spend far less time writing low-level code and far more time shaping systems, teams, and engineering cultures. The altitude is different, but the depth is not. If anything, the problems are bigger, more ambiguous, and more consequential.

It took me a while to realize that the blog can evolve with me.

Why Revive the Blog Now?

Engineering leadership today moves fast. AI is changing the developer workflow. Distributed systems are becoming more complex, not less. High-performing teams require clarity in decision-making, architecture, ownership, and operational discipline. These are the challenges that occupy my day now – and they’re also the topics I wish more people wrote honestly about.

Many engineers step into senior roles and suddenly find themselves solving problems they’ve never been trained for:

• How do you evaluate an architecture document when you’re not writing all the code yourself?

• How do you balance velocity with correctness at scale?

• How do you align teams without drowning in meetings?

• What does “raising the bar” actually mean in a large engineering organization?

These questions matter as much as the technology itself.

What to Expect Going Forward

This blog is shifting focus – but not abandoning depth. Here’s what I’ll be writing about in the coming months:

Technical Leadership

Practical frameworks, decision-making models, how to review designs, and how to stay technical as you grow into leadership.

Building and Scaling Engineering Teams

From mentoring senior engineers to managing managers, handling ambiguity, building culture, and navigating cross-org alignment.

Systems Thinking at Scale

Not AWS specifics, but the universal principles behind high-availability architectures, operational excellence, and cost-aware engineering.

Stories & Lessons From the Field

Without confidential details – but with honest reflections. The kind of things I wish I’d known earlier in my career.

Why This Matters

There’s a gap between the content written for new engineers and the content needed by people stepping into senior roles. Most engineers learn leadership the hard way – by stumbling through it.

If sharing my experiences helps even a handful of people make better decisions, grow faster, or avoid painful lessons, then reviving this blog is worth it.

Amazon API Gateway is a service that allows you to create, manage and secure APIs for your applications. One of the common use cases for API Gateway is to invoke AWS Lambda functions as backend services for your APIs. In this article, we will learn how to pass querystring or route parameters from your API requests to your Lambda functions using two different types of integrations: proxy and non-proxy.

Proxy integration

Proxy integration is the recommended approach for invoking Lambda functions from API Gateway, as it simplifies the configuration and reduces the latency of your API responses. With proxy integration, you can pass the raw request from the client to the Lambda function as-is, without having to define any mapping templates or transformations. The Lambda function can access the request parameters such as headers, query strings, path parameters and body from the event object that is passed as an argument.

To enable proxy integration for your API method, follow these steps:

1. Open the API Gateway console and choose your API.
2. Choose the resource and the HTTP method that you want to configure.
3. Choose Integration Request from the method execution panel.
4. Select Lambda Function as the integration type and check the box for Use Lambda Proxy integration.
5. Select the region and the name of your Lambda function and choose Save.

Now you can test your API method using the Test button on the method execution panel. You can enter any querystring or path parameters in the URL and see how they are passed to the Lambda function in the event object.

For example, if you have a GET method for /user/{name} resource and you invoke it with /user/bob?age=25, you will see something like this in the event object:

{  "resource": "/user/{name}",  "path": "/user/bob",  "httpMethod": "GET",  "headers": {    // ...  },  "queryStringParameters": {    "age": "25"  },  "pathParameters": {    "name": "bob"  },  // ...}

You can access these parameters in your Lambda function code using dot notation, such as event.queryStringParameters.age or event.pathParameters.name.

Non-proxy integration

Non-proxy integration is another option for invoking Lambda functions from API Gateway, but it requires more configuration and adds some overhead to your API responses. With non-proxy integration, you have to define mapping templates that transform the request parameters into a JSON payload that is sent to the Lambda function. The Lambda function can access these parameters from the JSON payload that is passed as an argument.

To enable non-proxy integration for your API method, follow these steps:

1. Open the API Gateway console and choose your API.
2. Choose the resource and the HTTP method that you want to configure.
3. Choose Method Request from the method execution panel.
4. Expand the URL Query String Parameters section and add any querystring parameters that you want to pass to your Lambda function. For example, if you want to pass a name parameter, enter name in the Name field and check the box for Required.
5. Choose Integration Request from the method execution panel.
6. Select Lambda Function as the integration type and uncheck the box for Use Lambda Proxy integration.
7. Select the region and the name of your Lambda function and choose Save.
8. Expand the Mapping Templates section and click on Add mapping template.
9. Enter application/json in the Content-Type field and choose Method Request Passthrough from the Generate template dropdown menu.
10. Modify the template code to include any querystring or path parameters that you want to pass to your Lambda function. For example, if you want to pass a name parameter, add this line in the template code: "name": "$input.params('name')"
11. Choose Save and deploy your API.

Now you can test your API method using the Test button on the method execution panel. You can enter any querystring or path parameters in the URL and see how they are passed to the Lambda function in a JSON payload.

For example, if you have a GET method for /user resource and you invoke it with /user?name=bob, you will see something like this in the JSON payload:

{  "name": "bob"}

You can access these parameters in your Lambda function code using dot notation or bracket notation, such as event.name or event[‘name’].

More details on Proxy and Non-Proxy integrations:

Proxy integration is a type of integration where API Gateway passes the raw request from the client to the backend service (such as Lambda or HTTP endpoint) as-is, without any modifications or transformations. This means that you do not have to define any mapping templates or data mappings between the request and response parameters. The backend service can access the request parameters such as headers, query strings, path parameters and body from the event object (for Lambda) or the HTTP request object (for HTTP endpoint). Proxy integration simplifies the configuration and reduces the latency of your API responses. It also allows your backend service to evolve without having to change your API Gateway setup.

Non-proxy integration is a type of integration where API Gateway transforms the request from the client to a JSON payload that is sent to the backend service (such as Lambda or HTTP endpoint). This means that you have to define mapping templates and data mappings between the request and response parameters. The backend service can access the request parameters from the JSON payload that is passed as an argument. Non-proxy integration gives you more control and flexibility over your API design and behavior. It also allows you to reuse configured mapping templates for different backend services that have similar data formats.

The following table summarizes some of the key differences between proxy and non-proxy integration:

I hope this helps you understand the difference between proxy and non-proxy integration better.

Seeking SRE is a book that explores the diverse and evolving field of Site Reliability Engineering (SRE), which is a discipline that aims to ensure the reliability and performance of complex systems and applications. The book is curated and edited by David N. Blank-Edelman, and contains more than two dozen chapters written by different practitioners and leaders in the SRE world¹.

The book covers a wide range of topics, such as:

• Different ways of implementing SRE and SRE principles in various settings, such as startups, enterprises, third parties, and non-dedicated teams.
• How SRE relates to other approaches such as DevOps, incident management, observability, and chaos engineering.
• Specialties on the cutting edge that will soon be commonplace in SRE, such as machine learning, security, ethics, and sustainability.
• Best practices and technologies that make practicing SRE easier, such as metrics, dashboards, automation, playbooks, and postmortems.
• The important but rarely explored human side of SRE, such as hiring, interviewing, diversity, inclusion, burnout, culture, and communication.

The book is intended to bring readers into some of the important conversations going on in the SRE field right now, and to inspire them to seek their own ways of applying SRE principles to their own contexts. The book is not a prescriptive guide or a definitive reference, but rather a collection of perspectives and experiences that showcase the breadth and depth of SRE.

Some of the key takeaways from the book

• SRE is not a one-size-fits-all solution. It can be adapted to different organizations, teams, systems, and goals. There is no single right way to do SRE.
• SRE is not just about technical skills or tools. It also requires a mindset of continuous learning, improvement, collaboration, and ownership. It also involves balancing trade-offs between reliability and innovation.
• SRE is not only about systems. It is also about people. People are the ones who design, build, operate, maintain, and use systems. People are also the ones who can suffer from stress, fatigue, frustration, and dissatisfaction when systems fail or perform poorly. SRE should aim to improve both the quality of systems and the quality of life for people.

Seeking SRE is a book that explores the diverse and evolving field of Site Reliability Engineering (SRE), which is a discipline that aims to ensure the reliability and performance of complex systems and applications. The book contains more than two dozen chapters written by different practitioners and leaders in the SRE world, covering topics such as implementation strategies, best practices, cutting-edge specialties, and human aspects of SRE. The book is intended to bring readers into some of the important conversations going on in the SRE field right now, and to inspire them to seek their own ways of applying SRE principles to their own contexts. The book showcases the breadth and depth of SRE as a field that can be adapted to different situations and goals, that requires both technical skills and a mindset of continuous learning and improvement, and that involves balancing trade-offs between reliability and innovation while caring for both systems and people.

Some examples of SRE in practice

• Google, which pioneered the SRE model and has shared its best practices and case studies on topics such as service level objectives (SLOs), incident management, postmortems, and automation.
• PagerDuty, which provides a platform for incident response and has adopted and adapted the Incident Command System (ICS) framework to coordinate and communicate during incidents.
• Standard Chartered Bank, which has been implementing SRE as its primary support model and has improved its engineering culture and capabilities, as well as its reliability and performance metrics.
• Moogsoft, which provides an observability platform that leverages artificial intelligence and automation to help SRE teams detect and resolve incidents faster and more efficiently.

Some challenges of implementing SRE

• Following the methodology: SRE is a prescriptive approach that requires a clear understanding of its principles, practices, and tools. It also requires a commitment to adopt a culture of reliability, ownership, and collaboration among different teams and stakeholders.
• SRE training: SRE involves a combination of technical skills and soft skills that may not be readily available or familiar to existing engineers or operators. It may require investing in training programs, mentoring, or hiring to build up the SRE capabilities and mindset.
• Getting stakeholders on your side: SRE may face resistance or skepticism from some stakeholders who are used to traditional ways of working or who are concerned about the costs or risks of changing the status quo. It may require convincing them of the benefits and value of SRE, as well as addressing their fears and expectations.
• Simulations: SRE relies on simulations such as load testing, chaos engineering, and disaster recovery drills to test and improve the reliability and resilience of systems. However, these simulations may be challenging to design, execute, and analyze, especially for complex or distributed systems.
• Finding practitioners: SRE is a relatively new and evolving field that may not have a large pool of experienced or qualified practitioners. It may be hard to find or recruit SREs who have the right mix of skills, knowledge, and attitude for the role.

Image from mps360.com

To give a third-party application read-only access to your AWS account information, you can use the AWS Identity and Access Management (IAM) service. Here are the steps:

1. Create an IAM user for the third-party application with read-only permissions.
2. Attach a policy to the user that grants read-only access to the AWS resources you want the third-party application to access.
3. Generate an AWS Access Key ID and Secret Access Key for the user, which the third-party application can use to authenticate API requests.
4. Provide the third-party application with the AWS Access Key ID, Secret Access Key, and the AWS region to be used.

Note: Be cautious when granting access to a third-party application and make sure to review the permissions you are granting and the data that will be accessible.

Image from https://arstechnica.com/

Generative AI seems to be everywhere these days and the bets are, this is jut the beginning and it will be more present in our lives in several industries. Here are just a few to expect:

In the next 2 to 3 years, we can expect to see an increase in the adoption of generative AI across several industries including:

1. Healthcare: Generative AI can help in drug discovery, personalized treatment plans and analysis of medical images.
2. Art & Design: AI-powered tools will become more accessible to artists, designers and marketers for creating unique visual content.
3. E-commerce: AI models can generate product descriptions, customer reviews, and product recommendations.
4. Finance: AI-powered tools will be used for fraud detection, credit scoring, and financial forecasting.
5. Manufacturing: Generative AI can help in creating optimized production schedules, improving supply chain management, and prototyping new products.

However, it is important to note that AI adoption will also depend on the specific limitations and ethical considerations of the industry, as well as the progress of AI research and development.

How long until the government will try to regulate generative AI?

It’s difficult to predict exactly when governments will start to regulate generative AI, as it depends on a variety of factors such as the pace of AI development, public opinion, and government priorities. However, with the increasing use and potential impact of generative AI, it is likely that governments will start taking regulatory measures in the near future.

In recent years, governments around the world have started taking steps to regulate AI and its applications. For example, the European Union has introduced the General Data Protection Regulation (GDPR) which affects AI applications, and some countries have started to consider regulations specifically targeting AI.

It’s important for governments to balance the benefits and potential risks of generative AI, while also considering the impact on businesses, citizens, and the overall economy. Overall, it can be expected that the regulation of generative AI will be a gradual process, shaped by a combination of technical advancements and public discourse.

Image from Forbes.com

As a mentor, you should operate at 3 levels:

1. Goals: Figuring out what they really want

2. Situations: Handling the unfamiliar or difficult

3. Skills : Getting promoted

Goals

Telling someone what they should want isn’t as powerful as helping them discover it for themself.

Goals are most meaningful when they are deeply understood.

The best goals come from within.

In the simplest form, it’s the “where do you see yourself in five years?” question, but that’s a big leap for most people to take in a way that’s authentic and not what they think they ought to say or what the mentor wants to hear.

Instead, probe for how well they understand their current situation:

• What’s going well?
• What’s not going well?
• What about your role do you enjoy the most?
• What’s most frustrating?
• If you could change one thing, what would it be and why?

SITUATIONS

To mentor situations, tell stories.

Faced with the question “what should I do?”, a mentor should resist the urge to recommend and should look for an opportunity to tell a personal story instead.

Why answer indirectly with a story?

• Sharing a related experience reassures a mentee that they’re not alone
• Stories engage the listener’s brain, helping them focus more completely on what they’re being told rather than their own problems
• Stories let a mentee consider a situation through an abstraction — when they aren’t the protagonist of their own, immediate problem, they have a chance to see a situation more objectively and consider different perspectives.
• Finally, it preserves their agency and sense of control. A story is a teaching tool — “this worked for me” — but you leave the decisions up to them.

IMPORTANT: Be honest if you haven’t experienced a situation personally.

SKILLS

To mentor skills, you have to observe the mentee’s in action or output.

• For coding skills, code review or pair programming.
• For communication skills, sit in on a meeting they expect to actively participate in or watch them practice a presentation.
• For technical writing, read what they’ve written.

The MOST IMPORTANT thing ON MENTORING is to PROVIDE ACTIONABLE FEEDBACK.

It means being specific about your observations, what they need to learn or practice in order to improve & providing direction about what they could have done differently.

If your mentee doesn’t know what to do next, your feedback wasn’t actionable.

Mentoring is about listening.

Resist the temptation to offer unsolicited advice.

Final Tip: Use The Career Ladder for Growth Conversations w/ your Mentor:

Look at the level above your current one.

For every item, ask:

• Where do you see me on this?
• What am I missing, specifically?
• What steps can I take to demonstrate it?
• What support will I need to do that?

This used to be a really hard problem on AWS but not anymore (At least for most of the resource types).

AWS Resource Explorer is a tool that allows you to explore and discover the resources in your AWS account. It allows you to view, search, and filter the resources across all regions and services in your AWS account.

You can use the Resource Explorer to list all the resources available in your AWS account by following these steps:

1. Go to the AWS Resource Explorer website (https://aws.amazon.com/resource-explorer/)
2. Sign in to your AWS account if prompted.
3. On the homepage, you will see a list of all the services that are supported by Resource Explorer.
4. Select the service that you want to view resources for.
5. You can use the search bar or filter options to narrow down the list of resources.
6. The resources will be displayed in a tree-like structure, you can click on a resource to view more information about it.

You can also use the AWS CLI or SDKs to access the Resource Explorer.

aws resource-explorer list-resources command in the AWS CLI can be used to list all the available resources in the account.

To use the AWS SDK, you can use the SDK’s API calls to list the resources available in your account.

It’s important to note that the Resource Explorer is a relatively new service and not all resources and services are available on it yet.

Image from github.om

Scrapy is an open-source and collaborative web crawling framework for Python. It is used for extracting the data from websites and can be used for a wide range of purposes such as data mining, data processing or historical archival. Scrapy provides an integrated way for following links and extracting data from the pages it crawls, and it can also be extended to handle more advanced functionality such as logging in to websites or handling cookies.

Scrapy allows you to extract structured data from websites using its built-in support for selecting and extracting data using CSS selectors and XPath expressions. Here is a general process of how to extract structured data using Scrapy:

1. Create a new Scrapy project using the command scrapy startproject projectname.
2. Create a new spider using the command scrapy genspider spidername website.com.
3. Define the start URL(s) for the spider by adding them to the start_urls list in the spider class.
4. Define a parse method in the spider class that will be called with the HTTP response of the start URL(s).
5. Use the response.css() or response.xpath() method to select elements from the page and extract the data you want.
6. Define the structure of the extracted data by creating an item class that inherits from scrapy.Item and defines the fields you want to extract.
7. Use the yield statement to return an instance of the item class populated with the extracted data.
8. Run the spider using the command scrapy crawl spidername

Here is a simple example of how to extract data from a webpage using Scrapy:

import scrapyclass MySpider(scrapy.Spider):    name = "myspider"    start_urls = ["http://www.example.com"]    def parse(self, response):        title = response.css("title::text").get()        yield {"title": title}

This example spider will extract the title of the page from the start URL and return it as a dictionary. You can then use the yield statement to return an instance of the item class instead of a dictionary.

Image from https://betterprogramming.pub/

In Python, the “yield” keyword is used in the body of a function definition. When a function is called with a “yield” statement, it returns a generator object, but does not start execution immediately. The code in the function is executed only when the generator’s next() method is called. Each time the yield statement is executed, the function’s state is saved and the function is suspended, so that when the function is later resumed, execution continues from the point at which it was suspended. This allows the function to produce a series of values over time, rather than computing them all at once and returning them in a list, for example.

Here’s an example of a simple function that uses the “yield” keyword:

def simple_generator():    yield 1    yield 2    yield 3for i in simple_generator():    print(i)

This will output:

123

Here’s another example that uses a loop to generate a sequence of numbers:

def count_up_to(max):    count = 1    while count <= max:        yield count        count += 1for num in count_up_to(5):    print(num)

This will output:

12345

It’s important to note that when a generator function is called, it returns a generator object, but does not start execution immediately. The code in the function is only executed when the generator’s next() method is called. In the above examples, the for loop called the generator’s next() method behind the scene and that’s why the code inside the function was executed.