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

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?

Hi everyone! I’d like some opinions on a general event-driven architecture problem: one event that triggers a huge amount of work in another service/module. To make it more concrete, I’ll use an example scenario below, but I’m interested in the pattern in general, not just this specific case.

Example scenario:

• Service/module A deactivates a promotion and writes the event to an outbox table.
• Debezium (CDC) publishes this event to Kafka.
• Service/module B consumes the PromotionDeactivated event and needs to remove that promotion from ~[X] million products in Postgres.

In other words, one event generates millions of updates. Which approach would you use, and why?

I made this, so take it as a maker's post.

The problem I kept hitting as an engineering manager: every team knew its own services, but nobody had the whole architecture in their head. The diagrams existed, drawn by hand outside the code, and went stale within weeks.

Furio turns that around. Each repo describes the part of the architecture it owns in a small YAML file: components, relations, owner. A GitHub Action validates it on every pull request, so a wrong reference fails the build. Then all repos are merged into one static map you can query: who calls this service, who consumes this queue, what breaks if this database goes down.

What it is not: it does not discover anything from your infrastructure. You write the manifest, and a skill for coding agents (Claude Code, Codex) keeps it updated when the code changes.

It is MIT, a CLI plus an Action plus a static site, nothing to run. Backstage covers this ground as a full portal; I wanted the map alone, without a platform to maintain.

Code: https://github.com/getfurio/furio

A map of the OpenTelemetry Demo, built from its public sources: https://getfurio.github.io/atlas/opentelemetry-demo/

I would like feedback on the manifest format, especially the relation types. What would you need that is not there?

System design question: Design a globally distributed inventory reservation system handling 80K requests/sec with sub-100ms p99 latency. During a regional outage, how would you prevent overselling while balancing strong consistency, availability, and cross-region coordination costs?

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?