reemdalvi/

Philosophical Undertones of Susanna Clarke's Piranesi

Unknown — Sun, 19 Oct 2025 00:00:00 +0000

⚠️ Contains spoilers ⚠️

Piranesi is a novel that looks simple on the surface, yet it opens into questions about reality, knowledge, and selfhood. The House in the story is both a place and an idea. It works as a physical maze but it also reads like a model of the mind, or even a modern echo of Plato's cave. Piranesi trusts his senses completely and takes the House as the whole world. Within his own frame of reference, everything makes sense, although it is far from the full picture.

That's a deeply philosophical idea: Is truth determined by internal coherence or by correspondence with an external reality? Piranesi only begins to understand the truth when he notices small irregularities. His world does not collapse in a single moment, it loosens slowly as those cracks become impossible to ignore.

The novel also ties memory to identity. Clarke suggests that who we are depends on the stories we hold in our minds and the language we use to make sense of them. Without that narrative, as in Piranesi's case, a person is reduced to something innocent and unburdened, although also profoundly alone.

Epistemology and the limits of reasoning

Piranesi approaches the House with careful attention. He observes, records, and constructs a rational picture of his environment. The problem is that his entire system rests on an incorrect premise. Clarke hints at a familiar philosophical concern. Even if our thinking is sound, it can still mislead us when our starting assumptions are wrong. This recalls Descartes and Kant, who both raised doubts about how far reason can carry us if the structure of perception itself is uncertain.

Solitude and clarity

Piranesi's purity comes from his isolation. Cut off from manipulation, fear, and ambition, he becomes almost a moral ideal, shaped by patience and openness. This echoes Rousseau's idea of the noble savage and the older spiritual traditions that view solitude as a path to clear sight. His lack of worldly knowledge is not foolishness, it is a different form of clarity.

Memory and the self

Piranesi's forgotten past raises the possibility that identity is neither fixed nor continuous. Once his life as Matthew Rose Sorenson is uncovered, we have to ask whether he is still that person or if he has become someone entirely different. Clarke hints that moral renewal might require letting go of the stories we cling to, a kind of inner reset.

Knowledge, power, and their moral cost

Characters like the Other reflect a darker approach to knowledge. He seeks information as a form of control, not understanding. In contrast, Piranesi relates to the House with respect and even devotion. The novel pushes back against the idea that knowledge should dominate. It suggests that wonder, humility, and attention can be more honest ways of engaging with the world.

The House as a picture of the mind

If you read the House as a symbolic universe, or as the inner architecture of the mind, it becomes a model of a vast but ordered reality. Every hall and statue becomes an image, an archetype, or an idea. The House supports meaning and life, yet it is built from perception and memory rather than direct truth.

Perhaps our world is similar to Piranesi's. We create sciences, philosophies, and belief systems that work coherently within the limits of human perception, but we cannot step outside those limits to check the foundation itself.

Question is should we chase an ultimate truth that might lie beyond our reach, or should we live meaningfully within the structures we have?

The Other pursue knowledge as conquest, and this hunger destroys him. Their ambition represents a distorted form of the human urge to overcome limitation. Piranesi, on the other hand, accepts the world before him and listens to it. This acceptance is not passivity, it is a form of wisdom grounded in experience rather than control.

Clarke offers an inversion of a familiar philosophical tale. Instead of celebrating the one who breaks out of illusion, she highlights the insight that comes from recognising our limits and still finding beauty within them.

The novel ties this back to ethics. The arrogance of the Other leads to cruelty and blindness, while Piranesi's humility creates compassion and a sense of wonder. What we believe about knowledge shapes how we behave. In the end, the way we know the world becomes inseparable from the way we live in it.

The Birth of Digital Consciousness: Reading Greg Egan's Diaspora

Unknown — Tue, 26 Aug 2025 00:00:00 +0000

Diaspora is a hard sci-fi read that imagines a post-human future where digital consciousness exists. This piece only reflects on the opening chapters that resonated with me most about the evolution of consciousness.

It began with a portrayal of a digital mind coming into being, a kind of artificial embryogenesis, in what feels like a computational echo of biological development.

An analogy with real-world embryology, where chemical signals activate genes to differentiate the body into parts like the head or thorax. Here, the raw structure of a consciousness is shaped by evolving algorithms.

Early in its existence, the mind isn't aware of itself. It's just a set of independent components parsing the environment, interpreting signals through structures like infotropes, which I read as a kind of digital cortex.

Then there are the input and output navigators, which function like sensory and motor systems.

It had learnt to single out one or two threads from the symbols' endless thousand-strand argument. It had learnt to narrate its own experience.

Beneath every moment of experience, there's a vast, silent machinery at work - complex, automatic, and mostly forgotten.

As the digital being (Yatima) evolves, it starts interacting with others, learning to treat the world as a space of patterns and puzzles.

Eventually, through these interactions and reflections, it forms a coherent model of self and becomes self-aware.

I was left wondering if self-awareness was a necessary byproduct of parsing the world effectively? Or, a threshold we cross only under certain cognitive conditions?

Yatima is drawn to the truth mines which are immersive mathematical spaces where digital minds test theorems, explore logical structures, and, most importantly, attempt to understand.

Not just in the sense of storing or retrieving information, but in the deeper sense: making an idea part of oneself. For a digital mind, understanding isn't about downloading facts. It's about embedding those facts into the larger symbolic framework of thought, linking them with past experiences, current knowledge, and future implications.

Understanding an idea meant entangling it so thoroughly with all the other symbols in your mind that it changed the way you thought about everything.

It reframes understanding as a kind of internal transformation, not acquisition but integration.

The concept of an outlook also stood out. In the polis, an outlook is a mental framework, a lens through which one interprets reality.

Citizens can take a copy of another's outlook to see the world from their perspective. It's a literal, computational form of empathy, not abstract or symbolic, but structural.

In our world, we're often told to “put ourselves in someone else's shoes,” but rarely asked what that actually means. Diaspora answers that: it means altering the very conditions under which thought occurs.

Yatima wonders if every part of the mind can be restructured: memory, preferences, logic then what remains? There must be an immutable region: some kernel of identity that persists across change. Otherwise, what anchors selfhood?

Diaspora explores this with clarity, defining the self not through narrative or symbolism, but through information, systems, and function.

These early explorations shows a being coming into the world, not through instinct or tradition, but through intentional cognition, shaping itself by asking: what it means to be, to understand, and to seek truth.

AWS RDS Subnet Migration

Unknown — Mon, 05 May 2025 00:00:00 +0000

Overview

I'll walk through how to migrate AWS RDS instances from public subnets to private subnets within the same VPC without recreating the database. The method minimises downtime beyond a controlled failover using built-in AWS functionality.

This post assumes you're using Amazon RDS (e.g. PostgreSQL or MySQL), with Multi-AZ deployment enabled, and your DB is currently hosted in a public subnet.

Why it matters

RDS instances placed in public subnets are reachable via a public IP if they are marked as publicly accessible. Even if properly restricted with security groups, this is unnecessary exposure. The best practice is to deploy RDS instances in private subnets to eliminate any potential public routing path.

The challenge is that you can't simply change the subnet group of an existing RDS instance within the same VPC. AWS doesn't allow that through the console or CLI once the instance is created, and many teams assume this requires snapshotting and recreating the DB, which comes with downtime and operational risk.

Fortunately, there's a workaround that uses Multi-AZ failover to force the DB into private subnets safely and with minimal disruption.

The Plan

Reconfigure the subnet group to include private subnets
Use Multi-AZ failover to shift the primary into one of them
Remove public subnets from the subnet group once they are no longer in use

Steps taken

Take a Snapshot

Although the process is safe, taking a snapshot is a good precaution. It provides a rollback point in case anything unexpected occurs.

Disable Multi-AZ temporarily

You can't remove or add subnets to a DB subnet group while they are in active use. Disabling Multi-AZ drops the standby and frees you to edit the subnet group.

Edit the Subnet group

Remove any public subnets not being used. Add private subnets that span at least three availability zones.

Re-enable Multi-AZ

This triggers AWS to provision a new standby in one of the available private subnets.

Reboot with Failover

It promotes the private standby to become the new primary, moving the live instance into a private subnet.

Disable Multi-AZ again

This removes the remaining standby instance.

Remove the final public subnet

Now that no part of the RDS deployment uses the public subnet, you can remove it cleanly from the subnet group.

Re-enable Multi-AZ (final)

Enabling Multi-AZ again will create a new standby in one of the private subnets, completing the migration.

Observations

Failover causes the only real downtime: this is expected and manageable
Disabling/enabling Multi-AZ also caused a brief I/O pause, especially once the instance was already in a private subnet
dig <rds-endpoint> was useful for verifying IP changes and subnet shifts during the migration

Takeaways

This approach avoids the need to snapshot and restore or spin up a new DB instance. It leverages AWS's own failover mechanism to move a live production database into a secure, isolated network space with minimal effort and downtime.

If you're still running RDS in a public subnet, you can migrate it safely without a full rebuild, just understand the timing and plan for the short outage when failover occurs.

AWS Elastic Beanstalk Load Balancer

Unknown — Wed, 02 Apr 2025 00:00:00 +0000

When deploying applications on AWS Elastic Beanstalk (EB), you have two main options for handling load balancing: let Beanstalk manage it for you automatically, or manually configure your own Application Load Balancer (ALB) and hook it into your environment.

Manual EC2 + ALB (Custom Infrastructure)

This approach gives you full control over every part of your architecture. You manage EC2 instances, the ALB, security groups, scaling policies, and networking. It's ideal for production-grade setups, custom routing logic, and when you need fine-tuned control over TLS, autoscaling, and deployment strategies.

But that power comes with a cost: it's slower to set up, requires solid AWS knowledge, and involves more ongoing maintenance.

Elastic Beanstalk (Load-Balanced Mode)

Elastic Beanstalk offers a simplified, managed path for deploying applications, especially when you're focused on getting something up and running quickly. It handles most of the heavy lifting for you: provisioning infrastructure, health monitoring, autoscaling, and even basic CI/CD hooks.

However, this convenience comes with trade-offs in control and transparency. Beanstalk can abstract away critical pieces of infrastructure, and small changes (like a platform upgrade) can unintentionally trigger major infra changes like recreating load balancers or breaking TLS setups.

When SSL/TLS Handshakes Fail Silently

Setting up HTTPS for your application on AWS Elastic Beanstalk seems straightforward, until it isn't. If you're not careful with how TLS is configured, especially in load-balanced environments, you can end up in a situation where clients silently fail to connect and you have no logs, no errors, and no visibility.

Scenario: Upgrading Your Beanstalk Environment

You're using Elastic Beanstalk to manage a Node.js application. It's deployed in a load-balanced environment using a default Beanstalk-managed ALB (Application Load Balancer). At some point, you upgrade the platform to a latest version.

As part of the upgrade, a new security policy was attached which uses stricter cipher suites or limited TLS version support.

The deployment goes live. Beanstalk reports success. Health checks are green. No alarms are triggered.

Problem: Certain Clients Can't Connect

Without realising it, you've now made your application inaccessible to some clients. Specifically:

Clients using older TLS libraries
Legacy systems that only support outdated cipher suites
Browsers or mobile devices in locked-down environments

These clients attempt to connect but fail during the TLS handshake. Since the request never completes, it doesn't reach your application and it doesn't even show up in your app logs.

To make matters worse, ALB access logs weren't enabled, so you have zero trace of the failed handshakes at the infrastructure level.

Why This Happens

TLS handshakes fail before the HTTP request is made.
The ALB doesn't forward anything to your app so your app knows nothing.
If access logging on the ALB is disabled (which is the default), you have no visibility into the failure.
Beanstalk's “all green” status is based on internal health checks, not edge-case TLS compatibility.

How to Avoid this

Verify TLS compatibility before deploying a new policy (AWS Security policies)
If you serve legacy clients or B2B partners, assume there's at least one ancient TLS stack out there still hanging on
Have ALB logs enabled
Monitor for traffic drops, not just error rates

Final thoughts

These issues don't come from bad code, they come from small configuration changes with large ripple effects. In environments like Beanstalk where AWS handles infra for you, it's easy to forget how much is happening under the hood.

While the issue in this scenario stemmed from an TLS misconfiguration at the load balancer level, it was indirectly caused by the way the app was deployed. Because containers were not used, upgrading the Node.js version meant upgrading the entire Elastic Beanstalk platform, which in turn triggered infrastructure changes, including a new, stricter TLS policy.

If the application had been containerised, the Node.js version in the image was pinned and deployed as-is, without having to touch the load balancer or changing policies. It's a reminder that containerisation doesn't just make deployment more flexible, it reduces the risk of platform-coupled surprises.

Debugging a Production Nightmare

Unknown — Wed, 19 Mar 2025 00:00:00 +0000

I was assigned a seemingly simple task that spiralled into a production issue affecting unrelated parts of the system. What followed was a valuable (and painful) lesson in system design, JavaScript quirks, and the risks of shared mutable state in a monolithic architecture.

The setup

The system was a large monolith composed of multiple logical components all running in the same process. One of these components used a hardcoded list of “questions” as part of a dynamic form flow.

My task was to add a new question to this list. This was the first "new" question after the feature was first implemented almost a year ago.

No database migration, no configuration system, just append an object to a static array declared in code.

I wasn't thrilled about the hardcoded setup, but it was meant to be a low-risk change. I added the question, tested the feature, passed QA, and deployed to production.

The bug

The next day, a different component of the codebase started showing a pre-filled answer to this new question. Except no one had filled them in. There was no data entry. These answers were ghosts.

This should have been impossible.

I checked the database: nothing. I read through the code paths: nothing. I added logs directly in production. That's when I saw it.

The cause

The array of questions was being shared across modules, passed around by reference. Somewhere downstream, another part of the application was mutating that array, modifying it in place by appending answers.

So my new question, added to the shared array, started receiving mutations intended for other workflows. That corrupted shared state leaked across service boundaries and showed up in user-facing API responses.

const questions = 
[
    { id: "name", type: "text" },
	{ id: "age", type: "number" },
];

const  getAllQuestions = () => questions;

module.exports = getAllQuestions;

getAllQuestions was imported in various modules leading to adding an answer somewhere along the way...

The quick fix

Deep-copy the array before passing it between modules.

const getAllQuestions = () => JSON.parse(JSON.stringify(questions));

After that, everything worked as expected. The newly added question remained untouched, and the API behaviour stabilised.

Long-term fix

Deep-copying solved the immediate issue, but the real problem was deeper: the system had no clear boundaries or ownership of data, and critical config was being shared and mutated across modules.

A better long-term solution would involve moving the questions into a database where they are not entangled with application logic. Write tests that assert immutability and fail if shared structured are unexpectedly mutated.

Eventually, parts of the monolith should probably be refactored into loosely coupled services, or at least well-encapsulated modules that communicate through defined interfaces, not shared memory.

Final thoughts

const in JS/TS gives you a false sense of safety, it only protects the reference, not the contents.

Always assume your data can be mutated unless you've made it truly read-only.

If you're building anything more complex than a to-do list, shared mutable state is a trap. Wrap your arrays. Clone your objects. Trust no one. Especially not past developers. Especially not yourself.

And maybe, just maybe, don't hardcode production-critical data into a single shared array.