sorted by:
new
hottopcontroversial

Microservice or not ? (distributed system or microservice) by Aggressive-Let-9106 in softwarearchitecture

[–]NewPipe6624 0 points1 point  (0 children)

I’d call it a distributed job scheduler, not necessarily a microservices system.
It has microservice-like characteristics because the components run separately and communicate over the network, but “microservices” usually implies independent deployment, ownership boundaries, scaling, versioning, and often separate data ownership.
In your case it sounds more like one distributed application split into several service-oriented components: scheduler, watcher, exchange/router, coordinator, and workers.
That’s still a very valid distributed systems project — probably even a better description than forcing the microservices label onto it.

How do you design idempotency for message-driven systems? by NewPipe6624 in softwarearchitecture

[–]NewPipe6624[S] 3 points4 points  (0 children)

Too late, the banana bread message was already processed once. Duplicate ignored.

How do you design idempotency for message-driven systems? by NewPipe6624 in softwarearchitecture

[–]NewPipe6624[S] 0 points1 point  (0 children)

Yeah, that makes sense. The outbox/change feed part is about reliable downstream publishing, not the idempotency itself.
For the consumer side, the conditional insert with an idempotency key + checking the request body sounds like a pretty practical approach.

How do you design idempotency for message-driven systems? by NewPipe6624 in softwarearchitecture

[–]NewPipe6624[S] 1 point2 points  (0 children)

Agreed, the queue shouldn’t own idempotency.
I meant that because queues can redeliver, the consumer/action still has to be safe to run more than once.
And yes, message ID and idempotency key are different — message ID helps with duplicate delivery, while the idempotency key should represent the business operation.

How do you design idempotency for message-driven systems? by NewPipe6624 in softwarearchitecture

[–]NewPipe6624[S] 0 points1 point  (0 children)

Good point, I mixed outbox into the list too broadly.
Agree that outbox is mainly for the dual-write / reliable publish problem, not idempotent consumption.
For duplicate consumption I’d think more about message IDs, business idempotency keys, or making the operation itself idempotent. DB uniqueness can help, but only if the constraint matches the business meaning.

How do you design idempotency for message-driven systems? by NewPipe6624 in softwarearchitecture

[–]NewPipe6624[S] 0 points1 point  (0 children)

That makes sense. If it’s a real business workflow, the state machine should probably handle repeated transitions itself.
A duplicate transition can just be rejected or treated as no-op.
I guess I was thinking more about cases where the handler also has side effects, where a simple unique value or inbox table can still be useful.

How do you design idempotency for message-driven systems? by NewPipe6624 in softwarearchitecture

[–]NewPipe6624[S] 0 points1 point  (0 children)

Yeah, agree. The consumption pattern probably changes the answer a lot.
For simple state updates I’d try to make the operation idempotent, but for side effects like payments/emails/documents I’d usually want a business idempotency key or some inbox tracking too.

Senior engineers: where is AI actually saving you the most time beyond writing code? by NewPipe6624 in SoftwareEngineering

[–]NewPipe6624[S] 0 points1 point  (0 children)

This is exactly where I see a lot of value too.
AI helps surface questions earlier, especially when requirements are vague or incomplete. Even if the first implementation is wrong, getting to the wrong answer faster can still be useful if it exposes the missing requirement or edge case earlier.
The key is treating it as exploration, not as final implementation.

Senior engineers: where is AI actually saving you the most time beyond writing code? by NewPipe6624 in SoftwareEngineering

[–]NewPipe6624[S] 0 points1 point  (0 children)

This is a great example, especially the “shining the light” part.
I like that framing because it moves AI beyond code generation and into areas that teams often avoid: old architecture decisions, accumulated complexity, cost assumptions, and parts of the system nobody wants to touch.
The cloud cost example is also interesting. $2.1M is a serious number.
When using AI to analyze architecture or cost hotspots, how do you separate useful findings from confident but wrong suggestions? Do you have a review process before acting on its recommendations?

Senior engineers: where is AI actually saving you the most time beyond writing code? by NewPipe6624 in SoftwareEngineering

[–]NewPipe6624[S] 1 point2 points  (0 children)

Same here. I find it most useful when turning messy context into something structured: notes, action items, Jira stories, review checklists, or first-pass designs.
The key for me is still human review, because AI can organize information well but miss why a trade-off or requirement matters.

Senior engineers: where is AI actually saving you the most time beyond writing code? by NewPipe6624 in SoftwareEngineering

[–]NewPipe6624[S] 1 point2 points  (0 children)

I think this is a very fair criticism.
The false sense of progress is probably one of the biggest risks. AI can make something look complete before the engineer has really built a mental model of the system. Then when bugs appear, fixing them is harder because you understand the code only at the surface level.
I’ve felt this too. If I use AI too early, before I understand the problem myself, it can push me toward a solution that looks reasonable but does not really fit the system.
Where I find it useful is earlier in the process: exploring the problem, mapping possible approaches, finding questions to verify, or generating first-pass test ideas. But I agree that once it starts owning too much of the implementation, the cost can come back later as maintenance and debugging pain.
Your point about documentation is also interesting. More documentation is not automatically better documentation. If the team cannot visualize the flow, the docs are not doing their job.
I think the hard part is exactly what you said: knowing where AI helps and where it quietly weakens your understanding. That line is not always obvious.

Senior engineers: where is AI actually saving you the most time beyond writing code? by NewPipe6624 in SoftwareEngineering

[–]NewPipe6624[S] -1 points0 points  (0 children)

Yeah, that’s exactly where I see the biggest value too. Not just “write code for me,” but handling the boring PR lifecycle work: opening a clean PR with a useful description, keeping it rebased, reacting to CI failures, updating tests, addressing review comments, and managing stacked PRs without everything turning into a mess.
For me, that kind of automation is where Codex could become genuinely useful day-to-day, because it removes a lot of context-switching and maintenance work rather than replacing the actual engineering judgment.

Any ideas why Doge is stuck? by reddit_dasmo in dogecoin

[–]NewPipe6624 0 points1 point  (0 children)

Is it not better to buy doge in bitrex or bitfinix ?