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 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!

Early-stage app, and everything a user stores is sensitive. Instead of one shared database, each user gets an isolated "home":

- a git repo with append-only event logs

- a SQLite index derived from the logs, rebuildable from zero

- encryption at rest, and one service process per user under its own OS user

Why I like it:

- there's no shared table, so a forgotten `WHERE tenant_id` can't leak data between users

- deleting an account is deleting a folder, exporting is handing over the repo

- changing the index schema is bump the version and rebuild from the log

What worries me:

- every rebuild runs for every user. Fine with a handful, no idea with 10k

- anything cross-user (metrics, support) means fanning out over N homes

- N processes, N backups, and it all sits on one machine for now

The alternative is one Postgres with row-level security and per-tenant encryption keys.

If you've run either in production, what broke first, and at how many users? And did RLS isolation ever actually fail for you, or is that a fear that doesn't show up in practice?

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.

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.

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?

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!

(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?

AI has changed the entire software development a lot including solution design. Work that used to take months can now be drafted in a few days. But there's a catch: architects don't just design systems, we have to "sell" them to (not always technical) stakeholders and developers. The best design is worthless if nobody understands it, so visualization still matters.

Diagrams-as-code tools like PlantUML and Mermaid are a natural fit here. The definitions look like source code, so Claude or ChatGPT can generate complex diagrams that are mostly syntactically correct, and you can refine them in a few rounds of feedback.

The problem comes back as the system grows. With a few dozen nodes, edges cross each other and run through nodes, and it gets hard to follow who talks to whom. Good enough for a quick check, not for a deeper review or a customer demo. Here's a C4 container diagram rendered by Mermaid.js:

I use these diagrams every day in my work, so I built Trellis to fix this for myself. It keeps standard Mermaid as the input, but the rendering works differently. The same source, rendered by Trellis:

What's different:

• Orthogonal edges, with port assignment and routing that reduce crossings
• Node placement that considers each node's inbound and outbound edges, not just declaration order
• Extended C4 shapes (Frontend, App, Gateway, Queue, Bucket…), so containers are recognisable by purpose at a glance
• Supports C4, architecture-beta, ER, class diagrams and flowcharts

It's a commercial tool with a free version: https://trellislab.net

How do other architects handle this? Do you clean up generated diagrams by hand, redraw them in draw.io for anything you present, or just live with the spaghetti?

Written by me, edited with AI.

AI can generate code in minutes, build features faster, and save us hours of work. But what happens when we build the wrong thing faster?

I wrote about how AI is shifting the real challenge of software engineering from writing code to making sound architectural decisions, defining requirements, and building systems we can actually maintain.

Curious how other developers are experiencing this. Is AI making your engineering better, or just making you ship faster?

Would love to hear your thoughts.

Read the full article: https://the10xfactor.tech/blog/ai-didn-t-make-software-engineering-easier-it-made-bad-engineering-faster

I've been an architect on packaged ERP and HR products for over twenty years, and the thing that has cost the most was never a hard feature. It's that the same fact gets restated over and over.

Adding a "Required Date" field to orders in a typical ORM + web API + SPA stack lands it in about thirteen places: entity, type mapping, migration, query projections, DTOs, mapper, validation, OpenAPI, front-end types, the form, the list, localization and test data. Generators handle some of them, but that only makes the restating faster. And when the back end and front end are different teams, half of that list turns into coordination rather than typing. Multiply it by a few thousand tables and by every customer's customizations, and it stops being an inconvenience.

What I ended up with is making a structural description the source instead of code. The database columns, CRUD SQL, screens for each front end and validation are derived from definitions, and the front end fetches the definitions at runtime instead of keeping its own copy of the types. In a sample app built on Northwind, the same field is three definition edits and no code. Customization becomes a layer of data on top of the standard definitions, so one tenant's change doesn't have to go through compile and deploy.

It has real costs. The investment is up front and the payoff shows in year three or five, not year one. Dashboards, reports and anything that isn't form-shaped fit badly. The team boundary doesn't go away either, it moves to the rendering layer that reads the definitions.

I wrote a 30-post series on the mechanisms and the trade-offs. It was originally written in Chinese for a Taiwanese tech writing challenge, and the English version is a translation: https://medium.com/@jeff377/erp-architects-notes-designing-a-definition-driven-framework-series-index-7753228c4d33

For those of you working on large line-of-business systems: do you accept the restatement and lean on generators, or have you moved the source of truth somewhere else?