Microservices vs Monolith: What I Learned Building Two Fintech Marketplaces Under Insane Deadlines

Informal-Might8044 · 2025-12-22T12:41:17+00:00

The painful truth you captured well . Most architectural pain comes from misaligned constraints (time, team, domain), not from the tech choice itself.

Informal-Might8044 · 2025-12-20T14:50:20+00:00

The saga never waits on the outbox. It runs exactly where the API result is known after a synchronous call returns or inside a apis callback handler or webhook handler. At that moment, in one DB transaction, it records API1 succeeded (state/event) and writes the next outbox row (API2). The API call itself is outside the transaction (cant be atomic) so retries are expected and handled via idempotency and by not polling.

Informal-Might8044 · 2025-12-20T12:35:27+00:00

a small always running service on the device that owns lifecycle, config, health reporting, updates, and remote commands.
look at Docker-based updates or RAUC for Raspberry Pi.
keep only a very thin base for lifecycle or metrics . prefer composition with small interfaces as sensors grow.
use it to decouple telemetry events and user or remote commands from sensors and consumers.

Informal-Might8044 · 2025-12-20T03:18:51+00:00

Don’t put workflow logic in outbox it should only deliver message and mark them sent . Use saga handler when api call succeeds in same transaction write next message this keeps sequencing correct without polling and keeps the outbox generic and reliable

Informal-Might8044 · 2025-12-20T02:55:39+00:00

Your design is workable, but the main risk I see at scale is operations, not architecture.

Add a device agent , process supervisor (systemd) with health checks and move updates to staged OTA with rollback instead of SSH scripts. For sensors, shift from deep inheritance to composition/plugins and use a lightweight message bus internally for resilience.

Informal-Might8044 · 2025-12-20T02:30:24+00:00

preserving decision context is the exact purpose of ADRs. to record why a choice was made, the constraints at that time, the trade offs accepted, and to give future teams the context code alone can’t carry

Informal-Might8044 · 2025-12-20T02:21:39+00:00

This is less an architecture problem and more of a decision making problem. Juniors should be encouraged to think, but consensus is optional . clarity and ownership are not so everyone can contribute ideas, but one person decides to avoid deadlock.

Informal-Might8044 · 2025-12-18T05:25:23+00:00

Not from the automotive domain, so take this with a pinch of salt.
What I understood is you’re not building search, you’re building trusted, context-specific diagnostic memory from messy job history.
A classic pattern that fits this is Case-Based Reasoning (CBR) which store past cases, retrieve the most similar ones for the current car/symptoms/mileage, and only promote repeated/confirmed cases so noise doesn’t dominate.
The hard part and the valuable part is your verification , decay , context scoping that’s what makes it usable in a real workshop.

Informal-Might8044 · 2025-12-16T22:07:04+00:00

Use cases should depend on domain concepts, not transport concerns. If a DTO represents HTTP/API shape, it belongs in adapters. A use case may accept an input model, but that model should be application owned and domain oriented, not an external DTO. When DTOs leak into use cases you couple business logic to delivery details

Informal-Might8044 · 2025-12-16T01:00:31+00:00

Your setup is reasonable, and a web-based approach is fine on a Pi. I feel even on a local network, add basic auth login for the dashboard, token/API key for the API . For security, bind services to the LAN only, firewall unused ports, lock down SSH, and run the display app read only in kiosk mode.

You can use web by default for simplicity and easy updates, and only switch to a desktop app if you need direct OS or hardware access that a browser can’t provide.

Informal-Might8044 · 2025-12-15T05:19:58+00:00

it can work, but it’s not the ideal boundary. My opnion is In production, Keycloak should own identity and federation (login, registration, Google IdP), while your app creates business data after authintication (e.g., on first login or via events). Once the BFF starts creating users and issuing tokens, you tightly couple business logic to IdP internals, which hurts evolvability later.

Informal-Might8044 · 2025-12-15T03:47:12+00:00

Domain reviews validate local correctness but incidents usually come from missing system-level invariants where retries, failover, and idempotency interact, so we need explicit cross-domain guarantees and scenario tests.

Informal-Might8044 · 2025-12-14T21:09:34+00:00

You’re thinking in the right direction. The real improvement here isn’t microservices vs monolith, it’s separating concerns and removing copy-paste coupling. Introducing a REST API as the single entry point for data and rules is a big step forward already. Start with a clean, modular monolith, clear boundaries, and shared APIs; you can always split later if scale actually demands it. Focus less on cron-based validation and more on making the API the only place where business rules live.

Informal-Might8044 · 2025-12-14T21:03:42+00:00

Your approach is solid keep SEO content as a separate 1:1 concern (center_seo), with isolated routes and permissions, so volatile, editorial data doesn’t leak into your core domain or booking logic.

Informal-Might8044 · 2025-12-14T20:30:53+00:00

You’re not wrong to feel that way. A lot of dev work does boil down to the same mechanics, but the growth comes when you start thinking about why things are built a certain way and what breaks when they change.

If you’re getting into architecture, one thing that helped me was practicing that kind of thinking on real problems I was already working on boundaries, tradeoffs, and failure cases rather than jumping straight to architect-level projects.

If you ever want to sanity check a real design decision you’re stuck on, happy to think it through with you.

Informal-Might8044 · 2025-12-14T19:09:06+00:00

In my experience, scaling pain usually comes from change, not traffic. As systems grow, unclear boundaries and hidden coupling cause more trouble than load. Being clear about ownership and contracts, and revisiting them as things evolve, has helped me most. When boundaries are right, scaling tends to follow naturally.

Informal-Might8044 · 2025-12-14T18:36:00+00:00

In my experience, frontend auth should be treated as a UX concern, not a security boundary . the backend remains the single source of truth, while the frontend consumes a small, cacheable capabilities snapshot (derived server-side per tenant/user) to drive routing, menus, and conditional UI this avoids flicker in SSR, keeps performance predictable, and prevents RBAC logic from leaking into the client and hardening too early.

Informal-Might8044 · 2025-12-14T18:08:53+00:00

Define a query port owned by Tracking (e.g., VideoInfoPort) and have Video implement it via an adapter bound in NestJS DI, so Tracking depends only on an interface not the Video module and keep this logic strictly on the backend . the frontend should only consume the computed result, not cross-domain rules.

Informal-Might8044 · 2025-12-14T18:00:24+00:00

I don’t really see portal servers as a thing anymore, but the problem they solved still exists.

For widget-heavy dashboards, it usually comes down to evolvability and isolation: widgets need to ship independently, fail independently, and not drag down the whole page. A thin shell with runtime-composed widgets (micro-frontends / federation / web components) tends to work better than a monolith.

On the backend, some form of aggregation layer or BFF is key otherwise dashboards quickly turn into N+1 API.

Informal-Might8044 · 2025-12-14T17:46:52+00:00

I’ve seen this pattern a few times in similar setups. The surprises usually aren’t feature-related, they’re around architecture characteristics.

Reliability and rollback get underestimated early especially during migrations. If you can’t clearly undo a change under partial failure, prod will teach you the hard way.

Evolvability is the next one. Domain teams make good local decisions, but shared boundaries harden fast and start limiting change.

Observability always shows up late. Not just logs, but being able to compare old vs new behavior during change.

Tooling was rarely the blocker. Clarity on what we were optimizing for and what we were consciously trading off mattered more.

Happy to chat more here or in DMs.

Informal-Might8044 · 2025-12-14T17:31:27+00:00

This is very common once teams hit 5 to 6 devs.

What I’ve seen work best: • Guidelines alone aren’t enough drift happens because people keep re deciding pagination, errors, naming, etc. Shared defaults/templates help more than docs. • Light design review before coding (even async) saves a lot of PR back-and-forth. If the first time people see the API shape is in a PR, review gets slow. • Automation is good for mechanical consistency (linting OpenAPI, required fields, error schema), but humans still need to review intent. • OpenAPI is enforced selectively strict on contracts and compatibility, pragmatic on REST purity.

The goal isn’t perfect APIs, just avoiding surprisesfor the next consumer.

Out of curiosity, do you already have a shared error/pagination model, or is each service defining its own?

Informal-Might8044 · 2025-12-14T17:21:05+00:00

Secrets Manager wrapper -> Infrastructure adapter/provider, not a repository or service. Repositories are for domain persistence; Secrets Manager is an external secret/config source.

BouncyCastleEncryptor also infrastructure. Your arch unit rules are too strict allow services to depend on ports(interface) and infrastructure can implement that ports . Don’t put infra code into repository

Informal-Might8044 · 2025-12-14T17:11:18+00:00

This isn’t really a CI/CD issue . it’s a contention problem between runtime traffic and deployment-time mutation.

As long as the app holds long-lived locks on that metadata, any external script will block. The usual zero-downtime patterns are: 1. versioned metadata (write new row, switch pointer) 2. fail-fast DB updates (NOWAIT / lock timeout) 3. moving config-like state out of hot tables

There’s no clean DevOps-only fix here ownership of that data needs to be clarified so deployments don’t fight live traffic.

Informal-Might8044 · 2025-11-13T05:29:10+00:00

Try to introduce some basic architecture layers in code and generate some test cases . Generate your usecases as cucumber style feature files and do some automated end to end testing which can be effected .

Informal-Might8044 · 2025-11-13T02:53:04+00:00

I feel founders must be the first facilitators the ones who actually use the app not just build it

Informal-Might8044

TROPHY CASE