When people hear sustainable development, software engineering probably isn't the first thing that comes to mind.
Usually, we picture renewable energy, electric cars, green buildings, or a company presentation full of words like impact, future, and responsibility.
But there is another side of sustainability that developers and architects deal with every day.
It's what happens when your application gets 10x 4 more infrastructure?
Does a database query suddenly become 20 times more expensive?
Are you keeping machines running when nobody is using them?
Are you storing years of data that nobody reads?
And perhaps the uncomfortable one: did the system become more complicated simply because the team kept adding things?
That's where sustainability becomes an engineering problem rather than a marketing concept.
For me, sustainable software is mostly about building systems that don't constantly need more resources just to keep doing the same job.
1. Economic Sustainability: Fix the System Before Buying More Infrastructure
One of the easiest ways to waste money in software is to treat infrastructure as the solution to every performance problem.
The application is slow?
Add CPU.
Database is struggling?
Buy a bigger instance.
Traffic increased?
Add more servers.
Memory usage is high?
Throw RAM at it.
Sometimes that's exactly the right decision. But sometimes you're just paying more to hide a bad design.
AWS's Well-Architected Framework treats cost optimization and performance efficiency as separate but connected architectural concerns. Its guidance specifically recommends considering cost during architectural decisions, right-sizing resources, and continuously reviewing the resources that drive infrastructure spending.
A simple example is a database query.
Imagine something like:
SELECT *
FROM orders
WHERE customer_id = 18472
ORDER BY created_at DESC;
If customer_id isn't indexed properly, the application might still work perfectly with 500 records.
Then the database gets millions of rows.
Suddenly the same innocent-looking query becomes a production problem.
You can increase the database size, or you can ask a much better question:
Why is the database doing this much work in the first place?
Adding the right index, changing the query, reducing unnecessary columns, or redesigning how the data is accessed can sometimes remove the bottleneck without buying a larger machine.
That's sustainable architecture in a very practical sense.
You're making the system do less work.
Don't confuse scalability with throwing hardware at the problem
There's nothing inherently wrong with horizontal scaling, containers, serverless functions, or managed infrastructure.
The problem starts when infrastructure becomes a substitute for engineering.
A lightweight service that scales from 2 instances to 20 because demand actually increased is one thing.
A service that needs 20 instances because every request triggers unnecessary database calls is another.
The difference is architectural.
The same idea applies to serverless systems. Serverless isn't automatically "green", and containers aren't automatically efficient either. The actual workload matters.
A badly designed function running millions of unnecessary operations is still badly designed, even if it happens to be running in a serverless platform.
Reuse before rewrite
There's another form of sustainability that gets less attention: the codebase itself.
Not every old module needs to be rewritten.
Sometimes refactoring a painful component is enough.
A full rewrite means rebuilding behavior, tests, integrations, deployment pipelines, monitoring, edge cases, and all the strange little things the original system learned over the years.
Sometimes you absolutely should rewrite.
But "let's rewrite everything" shouldn't be the default response to technical debt.
A sustainable codebase is one that can evolve without requiring the team to burn down the entire house every few years.
2. Social Sustainability: The System Has Humans in the Loop
Here's something easy to forget when talking about architecture:
The people maintaining the system are part of the system.
If only one developer understands how authentication, payments, deployment, and database migrations work, you don't have a resilient architecture.
You have a knowledge bottleneck.
And eventually that bottleneck becomes a production risk.
Imagine a developer leaves the company.
Nobody knows why a particular service exists.
Nobody knows why a specific queue has a strange retry policy.
Nobody knows why deleting one database column breaks an unrelated reporting system.
The documentation says:
"Legacy logic. Don't touch."
That's not documentation.
That's a warning label.
Reduce knowledge silos
Good architecture isn't only about separating services.
It's also about making the system understandable.
Clear boundaries, useful documentation, sensible naming, tests, diagrams where they actually help, and explicit ownership all reduce the amount of tribal knowledge required to work on a system.
Domain-Driven Design can help here because it encourages teams to make business boundaries explicit instead of allowing everything to slowly become one giant blob of shared logic.
You don't need DDD everywhere.
A small application doesn't need a 40-page architecture document.
But when the domain becomes complicated, making the boundaries visible can save a lot of pain later.
Architecture should be discussable
Another useful practice is the architecture decision record, RFC, or similar design-review process.
The important part isn't the acronym.
It's the habit of writing down:
- What are we trying to solve?
- What options did we consider?
- What are the trade-offs?
- Why did we choose this approach?
- What could make us change the decision later?
That creates something much more valuable than a diagram nobody reads six months later.
It creates context.
And context is extremely useful when the original author isn't in the room anymore.
3. Accessibility Is Also Part of Sustainability
There is another human side that often gets left out of the conversation: accessibility.
A system that works beautifully for one group of users but becomes difficult or impossible to use for others isn't particularly sustainable from a product perspective.
The W3C's WCAG framework organizes accessibility around four principles: perceivable, operable, understandable, and robust.
That translates into very practical engineering decisions.
Can someone navigate the interface with a keyboard?
Does the form provide useful error messages?
Do buttons and controls have meaningful labels?
Does the application still work with assistive technologies?
Does the interface remain usable when the screen is zoomed?
These aren't just "frontend polish" issues.
They affect whether a product remains usable as its audience grows and as devices, browsers, and user needs change.
4. Environmental Sustainability: Software Still Runs on Physical Machines
This is where the conversation gets interesting.
Software feels abstract.
It's code.
It's APIs.
It's containers.
It's a Git repository.
But eventually, every instruction ends up running on physical hardware.
CPU cycles consume electricity.
Memory consumes electricity.
Storage consumes electricity.
Networking consumes electricity.
Data centers also require cooling and other infrastructure.
The Green Software Foundation's current work frames software sustainability around things such as energy efficiency, carbon efficiency, carbon awareness, hardware efficiency, and measurement.
So a useful question isn't simply:
"Is my application green?"
A better question is:
"How much physical work does my software require to deliver one unit of useful work?"
That changes how you look at optimization.
A database query is not just a database query
Suppose an endpoint loads 50,000 database rows, processes them in application memory, and finally returns 20 records.
It works.
But why did the application process 50,000 records to return 20?
Maybe the filtering belongs in the database.
Maybe pagination is missing.
Maybe the query needs an index.
Maybe the API is returning fields the client doesn't need.
The improvement isn't about making the code look prettier.
You're reducing actual work.
And that can mean less CPU time, less memory pressure, less I/O, less network traffic, and potentially less infrastructure.
That's a much more interesting definition of optimization.
Caching is useful, but it isn't magic
Caching can be another example.
If thousands of users request the same expensive piece of data, repeatedly calculating it or hitting the database for every request doesn't make much sense.
A cache such as Redis can reduce repeated computation and database traffic.
But caching everything isn't sustainable either.
Now you have another system to operate.
You have memory consumption.
You have cache invalidation.
You have synchronization problems.
You have stale-data decisions.
So the question shouldn't be:
"Can we add Redis?"
It should be:
"Where is repeated work happening, and is caching actually the cheapest way to remove it?"
That's a very different architectural conversation.
5. Measure the Work Instead of Guessing
One of the most useful developments in green software engineering is the move toward measurement.
The Green Software Foundation's Software Carbon Intensity specification, for example, provides a methodology for measuring the carbon impact of software and explicitly considers energy, hardware, and carbon intensity rather than treating "green" as a vague label.
You don't necessarily need to calculate a carbon score for every API endpoint tomorrow.
But the underlying idea is valuable:
measure something.
For example:
- CPU time per request
- memory usage
- database queries per request
- data transferred per request
- storage growth
- average response size
- infrastructure utilization
- energy consumption where measurable
Even a simple metric can expose waste.
If version B performs the same business operation with half the database queries and 30% less compute, you've got evidence.
Now optimization becomes engineering instead of storytelling.
6. Carbon Awareness Changes the Question
There's an interesting concept in green software that goes beyond simply making software more efficient: carbon awareness.
Not all electricity has the same carbon intensity at every location or every moment.
The Green Software Foundation describes carbon-aware computing as doing more when electricity is cleaner and less when it is more carbon-intensive.
That creates some interesting possibilities.
Imagine you have a batch workload that doesn't need to finish immediately:
- generating large reports
- processing analytics
- training certain models
- rebuilding indexes
- running backups
- processing large datasets
If the workload can safely move to a different time or region, the system could potentially run it when the electricity supply has a lower carbon intensity.
The Carbon Aware SDK is one example of tooling built around this idea, including choosing when or where workloads run based on emissions data.
Obviously, you don't apply this to everything.
A payment API can't simply tell a customer:
"Sorry, the grid looks dirty right now. Try again tomorrow."
Real-time systems have real-time requirements.
That's where architectural trade-offs matter.
7. Sustainability Is Mostly About Trade-offs
This is probably the part I find most interesting.
There isn't a universal architecture that is simultaneously:
- cheapest
- fastest
- simplest
- most reliable
- most secure
- easiest to maintain
- and lowest-carbon
You usually have to choose.
AWS itself describes Well-Architected as a framework built around six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. The framework explicitly recognizes that architectural decisions involve trade-offs based on business context.
For example, keeping extra infrastructure running may cost more, but it can make a mission-critical system more resilient.
Compressing everything may reduce bandwidth, but CPU usage can increase.
Aggressive caching may reduce database work, but increase memory usage.
Moving a workload to a cleaner region may reduce carbon impact, but introduce latency or compliance issues.
So "sustainable" doesn't mean blindly minimizing one number.
It means understanding the system well enough to make deliberate trade-offs.
Bottom Line
For me, sustainable software development comes down to a pretty simple idea:
Don't make the system work harder than it needs to.
That applies to infrastructure.
It applies to databases.
It applies to network traffic.
It applies to storage.
It applies to architecture.
And it even applies to the people maintaining the code.
If a system needs more servers every time the user count increases, ask why.
If the database is doing millions of unnecessary operations, investigate.
If nobody understands a critical service except one person, fix the knowledge bottleneck.
If you're storing data nobody will ever use again, question it.
If a workload can move to a cleaner time or location without affecting the business, maybe let it.
Sustainability isn't a green badge you attach to an architecture diagram.
It's what happens when engineers start treating resources, people, infrastructure, and long-term maintainability as part of the same system.
And honestly, that's probably a better definition of good engineering anyway.
Update Note
Originally published in 2023. Updated in October 2026 with deeper coverage of system architecture, cloud efficiency, green software engineering, accessibility, carbon awareness, measurement, and real-world engineering trade-offs.
Top comments (0)