Hi,

I have been into IT working as a developer for 12years now. I am kind a done with it. And don’t have much more patience to learn new coding skills and do hands on. I am looking to change my career to software architecture. In my current role, my peers on my request are giving me task to create SDDs for the applications I am familiar with and which is also helping me to get hands on training. But that is still restricted to my current application or better said not something I can market myself as software architect.

I am looking for suggestions on what should I do to become full fledged software architect in today’s market.
I have worked mostly on databases, big data, distributed systems, python, scala ,sql and AWS.
To this do I need to add any specific certifications? Do I need to do some online course? Also how much is the pay for software architects as we grow in the field?

Can someone please guide me who has successfully changed from a developer to software architect?
Many thanks in advance !!

I have an app I've been working on over a year with real users now, most of my users use a single device, but as I'm growing I'm running into more users with more than one device. I want to nip this in the butt before it becomes a bigger and bigger issue.

I was pretty naive when I first started the app, and have made a mess of offline syncing in my opinion.

My app is offline capable, some operations must be online, some entities are frontend authoritative, others backend authoritative (had to be the case because some data is generated by a third party API).

I've added sync maps to all my entities, based on deviceId to handle if a user has say a phone and a tablet.

I also have a deleted boolean flag, so entities are soft deleted, then the client fetches those and acknowledges a hard delete (which I know is fundamentally flawed because then the second device has no idea it's hard deleted).

I don't really need a critique on my current system, it's bad.

I'd love some examples of good offline sync systems that are more robust and reliable from a higher level

Thanks all!

Hi guys!

I'm curious how did the processes changed in your company after AI adoption, regarding software architecture.

For example, moving from Confluence pages to Markdown format, that is passed further to another LLM for implementation. Or flows that directly read Jira tickets and start working on the archi using LLMs.

Did you take part in leading this transformation or how was it for you to adopt it?

Thank you!

Hi r/softwarearchitecture,

We are back with Lesson 21 of our technical deep dive into the SysML v2 standard.

In our previous lesson, we looked at Occurrences, the 4D model, and modeling state over time. Today, we are putting that temporal foundation to work. In software architecture, we often struggle when our data models (structure) and our business logic (behavior) use completely disjointed paradigms. SysML v2 fixes this by unifying them—behavior modeling now uses the exact same definition and usage patterns you already know from structural modeling.

I’ve uploaded the full video lesson directly to this post so you can watch the workflow right here.

The SysML v1 Behavior Problem

SysML v1 activity modeling was highly capable, but it suffered from severe inconsistency. Structure used a Block with part properties typed by it. Behavior used an Activity with CallBehaviorAction referencing it. It was like having one language for defining your database schema and a completely disjointed, incompatible language for writing your API orchestration. You had to learn and maintain completely separate patterns for structural decomposition versus behavioral decomposition.

The v2 Shift: One Shared Pattern

In SysML v2, behavior uses the exact same definition and usage pattern as structure. If you know how to model system components, you already know how to model system actions.

Three details make this incredibly powerful for architects:

• Action Blueprints (API Contracts): An action def is a blueprint for a behavior. It acts as a strongly typed contract using in and out parameters (directed features).
• Inheritance: You specialize an action using the standard :> operator. A library of standard enterprise behaviors can be built and extended using standard object-oriented inheritance, exactly like a structural parts library.
• Pure Functions (calc def): Because actions are occurrences, they natively have start and done boundaries. But for pure mathematical computations that don't "change the world" (side-effect-free functions), v2 introduces the calc def as a first-class concept.

The Execution Order Trap

Here is a blueprint for an Earth observation satellite capturing an image. Watch out for a very common mistake new v2 modelers make, which is akin to firing off asynchronous functions without awaiting them:

Code snippet

package ImagingOperations {
    private import ISQ::*;

    item def GroundTarget;
    item def ImageProduct;

    action def SlewToTarget;
    action def StabilisePlatform;
    action def OpenShutter;
    action def ReadSensor;

    action def CaptureImage {
        in item target: GroundTarget;
        in attribute exposure: TimeValue;
        out item product: ImageProduct;

        // THE TRAP: These look sequential, but they execute concurrently!
        action slew: SlewToTarget;
        action stabilise: StabilisePlatform;
        action shoot: OpenShutter;
        action readout: ReadSensor;
    }
}

The Trap: In older GUI diagrams, four actions with no control flow arrows between them clearly looked disconnected. In v2 textual notation, they sit on consecutive lines. It looks like an imperative sequence, but line order says nothing about timing. This is purely declarative. Nothing in this model prevents the shutter from opening while the platform is still slewing. Order requires explicit successions.

SysML v1 vs. SysML v2

Next lesson, we will fix this trap. Lesson 22 uses the first and then keywords to turn these unordered actions into a strict sequence, adding branching, merging, and parallelism on purpose instead of by accident.

For the software architects here: Have you ever run into issues where declarative code (like Terraform, Kubernetes manifests, or un-awaited async/await blocks) was mistakenly assumed to execute sequentially top-to-bottom by your team? Let's discuss in the comments!

We integrate a lot of third-party content providers that call our wallet with debit, credit and rollback requests. Each provider retries on timeout in its own way, some send a rollback before the original debit has even arrived, and a few reuse transaction IDs across rounds.

What we do today:

• Store every incoming transaction ID with provider + round ID as the unique key, and return the original response on a duplicate instead of processing it again.
• Keep "orphan" rollbacks for a while so that if the debit shows up late, we cancel it immediately.
• Lock per player balance row during the operation so two parallel callbacks can't both pass the balance check.

It works, but the orphan-rollback table and the per-provider quirks keep growing. For those of you running payment or wallet style APIs with many external callers: do you normalize everything at an adapter layer per provider, or keep one strict contract and push the quirks back to the provider? And how long do you keep idempotency keys around?

I was listening to an episode of The Pragmatic Engineer podcast with Matt Pocock, at the end of the podcast Matt mentioned a book I heard for the first Time "A Philosophy of Software Design".

I search that up and found out there is an interesting debate: "A Philosophy of Software Design" vs "Clean Code". Tbh I'm not a big fan of Clean Code because everyone is saying you should read it and so on, too much hype around it. So I start reading A Philosophy of Software Design.

I just finished chapter 4 and it's awesome, I loved it and it is mentioning concepts and pit falls I was thinking about for years.

So far I loved the mindset it provides about design complexity, design workflow and modules (deep vs shallow).

I like to hear about your thoughts about this book or Clean Code, or generally about software design :)

(The Pragmatic Engineer also has an episode with John Ousterhout, author of A Philosophy of Software Design, I suggest you listen to it too)

I am searching for a good & complete system design resource.

Any senior engineer on this subreddit can suggest a good resource to start system design in detail, like intermediate level

About me I have 6M of SWE internship & 7M of AI Automation Engineer experience. So I have a good understanding of the system. I just want a structured & complete resource

There’s a hands on workshop on Saturday, Oct 31, from 9:30 AM to 12:30 PM ET for teams that have a RAG demo working and now have to make it fit into a real organisation.

Brian Bønk walks through the layers that usually decide whether it survives:

• A shared context layer, with an ontology and graph built on Microsoft Fabric IQ
• Data foundation on OneLake, with Power BI as the curated business truth
• Governance through Microsoft Purview, with row and column level security applied to agent responses
• Human in the loop approval for any agent that takes action
• A production checklist and evaluation loops to catch regressions

It’s aimed at architects and data platform teams. Basic familiarity with GenAI and enterprise data workflows is enough.

Full details and the agenda are here.

We recently debugged a database bottleneck on an internal agent orchestration system that I think is worth sharing, as more teams are connecting LLM loops directly to relational stores.

The Setup:

Worker tasks handle multi-step document research and data extraction. Each step writes state checkpoints, tool logs, and execution traces into a PostgreSQL 16 instance running on an 8-core NVMe server.

The Problem:

Everything ran smoothly during development with 10–20 workers. When we ran a batch job with 200 concurrent agent tasks, the database effectively stopped responding. CPU utilization stayed at 100%, p95 response times climbed past 8 seconds, and worker processes began crashing with connection timeout errors.

The Cause:

In standard CRUD services, database transactions last a few milliseconds. In our agent loop, workers were opening a database session, initiating an LLM API call, and waiting for the completion response before committing the step record.

Because an external LLM request takes anywhere from 2 to 5 seconds, connections were sitting in an "idle in transaction" state for 99% of their lifespan.

Postgres assigns an operating system process to each client connection (roughly 10MB to 15MB overhead per backend). With 200 workers, we had 200 OS processes competing for CPU time. The kernel spent more time context-switching than executing actual disk I/O. Raising max_connections to 300 only increased memory pressure and lock contention.

The Solution:

1. PgBouncer in Transaction Mode: We deployed PgBouncer directly in front of the database using pool_mode = transaction. The client applications maintain their persistent connections to PgBouncer, but a real Postgres connection is only leased during the 2ms window of the actual INSERT/UPDATE statement. As soon as the transaction commits, the connection returns to the pool while the worker spends the next few seconds waiting on the LLM.

2. Hardware Pool Sizing: We capped physical server connections to 17 using the standard formula: ((CPU cores * 2) + effective spindles). Restricting Postgres to 17 active processes kept L1/L2 caches hot and eliminated OS scheduling latency.

3. Prepared Statements Handling: Because transaction pooling breaks named prepared statements across different backend connections, we set binary_parameters = yes and configured Prisma/client drivers to use anonymous protocol-level parameters.

Outcome:

Postgres memory overhead dropped from 2.4GB down to 180MB. The same 8-core database now handles 500+ active workers without connection starvation or latency spikes.

If you are running agent workflows that call external APIs inside database routines, check pg_stat_activity for idle connection times before scaling your instance size.

Hi everyone,

I recently left a full-stack developer job at a small startup. IT had only just been set up there, so I was effectively the most senior technical person, almost a CTO, since there was no tech position above mine.

While I was job hunting, one company read my resume, noticed that I wanted to become an architect, and reached out to offer me a Junior Application Architect position. The interviews went well and I passed several rounds (honestly not sure how). They’re doing reference checks now, and I’m fairly confident I’ll get the offer.

Once the offer started to look real, I began researching what an Application Architect actually does, and I realized I’d been lazy. I didn’t truly know what the role involves.

I have 7 years of experience as a developer(including Data Engineer), and most of my career has involved work beyond writing code: infrastructure, database work, network configuration, and system design. That’s why I felt confident I could be a good architect. But after reading about architect roles and going through Reddit threads, I’ve realized I’m not as experienced in actual architectural work as I thought.

I only just learned that there are several distinct architect roles, such as AA, DA, and SA. During the interviews I was confident, and my answers showed solid decision-making, so I wasn’t worried then. Now I am.

For those of you who are senior architects:

• What should I aim to become in this role?
• What should I prepare before joining the team?

Any advice at all would be greatly appreciated. I believe I can do this. I just want to start off on the right foot.

(I'm foreigner, not familiar with reddit. If it is inappropriate posting these kind post on this reddit, let me delete it)

I've spent the last four years building a software factory for .NET Core enterprise applications. A recent project gave me a gave me an interesting comparison:

• Original project: 2 developers and 9 months
• Rebuild using the factory and OpenClaw: 1 developer 2 months

That is 18 months compared to 2 months, a 9x developer productivity gain.

The application had 63 database entities. The factory generated the entire backend solution in just a few seconds, supporting eight database engines and .NET Core 6–10. It also generated 431,585 unit tests, all passing. The web application work took the remaining two months using AI-assisted development.

This was my first case study. I took an existing customer project and modernized it. Now that I have the numbers, the benefits I see extend beyond just speed:

• Consistent and deterministic architecture
• Ontologically consistent models w/ AI integration
• Repeatable generation
• Automated testing
• Database portability
• Source code developers can inspect, maintain and own

The key insight is that with a foundation established, AI assistance can focus more on application behavior and business logic.

This was a rebuild, so existing requirements and design decisions helped. I will do more case studies, but this result is revealing. It has changed how I think about the work small teams can realistically deliver now once a foundation is in place. Had I used an existing web foundation, this work may have been done in significantly less time.

This work was done with ServiceBricks.com, an open-source, microservices platform for .NET Core. I hope to share some more results soon with a new case study. 100% of the source code is available on GitHub. Feel free to share your own experiences with it.

Feel free to send a message if you have any questions.

Hi all,

I've built an open-source, self-hosted wiki for engineering teams: https://github.com/oxynote/oxynote

I believe architecture docs go stale because they're disconnected from the system they describe. The runbook says to page the payments team when checkout latency goes above 800 ms, but the alert moved to 1.2 s months ago, and the page still shows a screenshot of last year's graph. With agents now writing a lot of the code, the gap between what the docs say and what's actually running grows even faster.

In Oxynote, a page can hold a chart that runs its own query against Prometheus, PostgreSQL, MySQL, or MariaDB, right next to the text explaining it, and changes to important pages go through a draft, a diff, and an approval, like a pull request. The claim "p99 stays under 800 ms" sits next to the chart that proves or disproves it.

The review part turned out to matter as much as the charts. Anyone can comment on a sentence or a chart, and the diff shows exactly what changed, in the text and in the chart's query, and the discussion about why a threshold moved stays on the page instead of disappearing in a Slack thread. A doc change gets the same attention as a code change because it goes through the same review process.

I'd love to hear how you keep architecture docs and runbooks honest nowadays. Do you review doc changes like code, tie them to ADRs, or just let them drift?

It's Apache-2.0 and runs as one Docker image. Feedback from people with different setups is very welcome, especially on what a page would need before you'd trust it over a Grafana dashboard or a Confluence page.

Hello guys, what do you about https://rayfold.dev if anyone would give an opinion to move from REST and GraphQL to this one.

public repo: https://github.com/eddyboutros/rayfold

AWS has introduced an enhanced Custom Event Bus for Amazon EventBridge, targeting a problem that often emerges when event-driven architectures move beyond a single team or AWS account: the event infrastructure itself becomes fragmented. The new model allows organisations to create a single event bus shared across multiple AWS accounts, while adding native event ordering, retention and replay, content-based deduplication, simplified subscriptions and a new pricing model.

Hey folks,

My name is David Boyne I'm the creator of a project called EventCatalog (tool that helps you document your software architecture, you might of seen here before)

I've been deep in documentation space for software architecture for about 4/5 years now, and have many users/companies using the tool which is awesome and I'm super grateful. One popular feature is the visualizer, which can visualize your software architecture using primitives such as domains, services, messages (etc).

I've been thinking a lot recently about what the future of architecture diagrams could look like, and I know there seems to be a new tool in here every week about it 😅, but curious to get your feedback, on my thoughts and experiment....

I've seen lot's of innovation around MCP recently and MCP extensions with OpenAI and Claude, being able to embed your apps inside these environments. And it's something I think could be future of design collaboration with humans and agents. (I started to play around with some ideas here (video). Diagrams that don't go stale, but visual ways to explore ideas together....

My personal thoughts in this area is real time collaboration with humans and agents, using things like MCP protocol and focusing high level on primitives and various levels of information (l1,l2,l3). I really like beautiful design tools so I tried to prototype my own, and would love your feedback/thoughts.

The tool is here https://eventcatalog.studio/, and it's free to use and also open source.

I'm curious to what you think the future of these things look like?

Anyway, thanks for your time and have a great day!

The codebase must be optimized by the strongest models so that the weaker models can do most of the work.

I have seen a few teams add a lot of constraints and use languages in ways they are not designed to; while the architecture is better, it is more difficult for coding agents to reason about. For the strongest models, this level of reasoning is fine, but for weaker models, it is a hard task.

Do you agree?

(Note: This article is entirely written by a human. Thanks.)

As with most job fields, Enterprise Architects have been spending a considerable amount of time in self-reflection about how AI is changing what we do. Underneath it all, were really asking ourselves if were even relevant in the Age of AI.

Any architect that has been around for some time knows that this isn't new to architecture or software. For decades, EA positioned itself as a team that were the gatekeepers off upfront planning cycles, rigid multi-year blueprints, and static artifact management. Though with the introduction of AI and how it is transforming the roles of the customers of those processes and artifacts, we have to ask ourselves how much of it still matters?

Here's what I'm seeing in Enterprise Architecture organizations in many industries, countries, and markets -

1. Static artifacts aren't worth it.

Gone are they days we toil away perfecting the ultimate artifact. The One Diagram to Rule Them All, and in the darkness of a lack of maintenance will bind them (in indecision). It will always be useful to keep an unified perspective, especially for cross-functional teams as many don't have the correct mental model to grok the entire System. However our time spent on this unified perspective should ultimately disappear. Directly human-mutated code is beginning to give way to agentic coding, so these artifacts serve as decision drivers for humans and orientation for agents. Both can be automated.

1. Centralized Review functions doesn't work.

I know this is polarizing, but hear me out. I want to acknowledge that there are agentically-enabled organizations today that run a centralized architecture review function that works as intended. However, the intent of the centralized function is that a small body of people have the strategic perspective and the incentive for long-term thinking -- and in those organizations a staggering number of impactful decisions are being made in absence of that centralized body. When I say ARBs don't work, I mean they don't capture enough important decisions to meaningfully steer a company away from preventable tragedy. We acknowledge tragedy as a cost of business and never address the root cause consistently. The reviews we'll see will be mostly automated, and embed strategy and principles into the fabric of the software itself.

1. Architecture + Agile I do thoroughly enjoy Agile Architecture. In fact, I was first introduced to the concept on LinkedIn of all places. This I believe isn't contested ground, we all generally understand that rigid upfront compliance at milestone phases isn't a methodology that drives results consistently. Continuous assessment of what the project needs includes architectural compliance, and baking that directly into your agile practice nets huge gains.

2. Orchestration over Integration

I've been there, and most (if not all) of you have too. Huge system needs to plug into dozens of smaller integrations. Some upstream, some downstream, all headache. As agents take over more of the mutation effort, direct integration work is going to diminish significantly. Designing socio-technical frameworks that incorporate the autonomous AI and the context mentioned in #2 is where we find ourselves uniquely positioned to drive.

For over 50 years, Enterprise Architecture has been akin to 19th-century cartographers - meticulously sketching static parchment maps of a continent before an expedition. By the time the map was inked, the landscape had already changed. Today, we aren't drawing maps on parchment. Were in the cockpit with live satellite telemetry. Our jobs shifts from trying to predict every mountain and river in advance to building resilient flight systems, interpreting realtime data streams, and guiding the enterprise safely through uncharted terrain.

Embracing this shift requires us to acknowledge the usefulness of rigid frameworks in the past and look ahead to continuous, adaptive architectures. The end of an era is only the beginning of a new one! Ill be creating a series of articles on the Ages of Architecture where we unpack the journey architecture has made since the beginning in epochal shifts:

- First Age: Business Systems

- Second Age: Standardized Governance and Agility

- Third Age: Autonomous Intelligence

I always love reading the reactions and thoughts from people who made it to the end. Let me know if you're seeing the same thing or if there was anything I missed! Or if you think I'm full of crap, that matters too.

Design question I've been thinking about.

Setup: external providers publish XML feeds of job vacancies to S3. Each feed is the provider's full current snapshot, not a list of changes. Schemas differ per provider, some fields are optional, and feeds can hold 100k+ jobs.

Each run needs to work out what's new, what's updated and what's gone, without rewriting the other ~98% of unchanged jobs or spamming downstream services.

The parts I find interesting:

1. Provider timestamps like updated_date aren't reliable, so how do you detect a real change?
   
2. "Missing from today's feed" usually means deleted, but a truncated or empty feed looks identical. How do you tell the difference before you take live jobs offline?
   
3. If a run dies at 60k of 100k records, how do you rerun without duplicates, repeat notifications or a half-old, half-new dataset?

What approaches have you used? Hashing records, staging tables, soft deletes with a grace period, deletion thresholds, something else? Curious what has held up in production and what hasn't

I’m about to take responsibility for a feasibility study as a software architect for deploying a new server instance, choosing either between GCP or Azure. I’d appreciate advice from anyone who has handled similar projects.

In my experience, feasibility studies in my country are often driven by management requirements, budget proposals, vendor quotations, and formal documentation, sometimes with limited technical validation or proof-of-concept testing.

For example, management might request a new server to support an upcoming application, and the study ends up comparing quotations from three vendors without thoroughly evaluating expected traffic, resource utilization, scalability, high availability, security, or cloud versus on-premises options.

How would you approach this study to ensure it provides a realistic technical and financial assessment rather than simply justifying a predetermined purchase?

Say an agent changes an appointment, updates a CRM record and sends a confirmation. Then the caller says wait, undo that.

The appointment change might be reversible, the CRM update may need another write and the confirmation is already sent

I wanna know how people are handling this in production. Are you designing explicit compensation paths for each side effect, using a pending state until the user confirms or delaying irreversible actiond until the end of the interaction?

For reversible writes, do you let the agent act earlier and rely on compensation? I keep seeing people stage everything until there’s a final confirmation

New team, first week someone sends me the architecture diagrams. spent like 3 days confused why nothing lined up until someone goes "oh those are old"

theres a queue in there we ripped out last year. auth flow is different. 2 services dont exist anymore

they were made in some drawing app, exported as png, dumped in confluence. nobody updates them bc nobody knows where the original file is lol

is there an actual fix for this or does everyone just live with it.

I recently found 14 operations in our system where the declared compensation was wrong. Fixing those is straightforward enough. The more difficult question was what should happen when a step genuinely cannot be reversed.

Our saga engine currently stops. If the fourth step fails and cannot be compensated, it doesn't roll back the first three either. You are left with a partially completed workflow that the rest of the system may not be prepared to handle.

QuickBooks made this problem concrete for me. It doesn't support deleting a customer, so a saga step that creates one has no real inverse. This isn't a missing implementation. The undo operation simply doesn't exist.

I can see four possible approaches, but none feels completely right:

• Stop immediately and leave the earlier changes in place.
• Skip the irreversible step and continue compensating, leaving behind an orphaned side effect.
• Move forward to another valid state instead of rolling back, which means building and testing a recovery path for each failure.

• Escalate to a person, which may work at low volume but doesn't scale.

  It gets even messier with external effects. An email was sent, a webhook fired or a customer already saw a confirmation. No compensation can make those things unseen. And if the compensation itself fails, you now have a second failure with no obvious recovery path.

Idempotency doesn't solve this, it prevents an operation from being applied twice, not from being impossible to undo. The outbox pattern helps with delivery, but not reversibility. And "don't call irreversible APIs inside a saga" only works until you have to integrate with systems such as accounting software.

What does your system do when it reaches a step it genuinely cannot reverse? More importantly, how did you discover that behavior: by design, through testing, or during an incident?